DEV Community: TypeDB

Why we built a polymorphic database

mifuneson2 — Fri, 20 Oct 2023 22:20:50 +0000

Database models have failed to keep up with the rapid evolution of programming languages, and modern applications must use complex layered architectures to manage data as result. In order to resolve this, we built TypeDB on a completely new, highly expressive database paradigm.

In this blog post we explore the origin and core ideas that led us to create a polymorphic database.

Why do we need a polymorphic database?

Relational databases lack the expressivity of model polymorphism. Programming languages are becoming increasingly more declarative, empowering engineers to quickly write safe and expressive code backed by static type checking and abstract data constructs. Relational databases were designed at a time when procedural programming languages were the norm. They are built on Codd’s relational algebra and implemented using tables and one-dimensional tuples.

Object-oriented programming involves complex modeling constructs such as abstraction, inheritance, and polymorphism, requiring the expression of multidimensional data structures.

// Class inheritance in Java

class User {
    String email;
    String name;

    User(String email, String name) {
        this.name = name;
        this.email = email;
    }
}

class Employee extends User {
    int employeeId;

    Employee(String email, String name, int employeeId) {
        super(email, name);
        this.employeeId = employeeId;
    }
}

class PartTimeEmployee extends Employee {
    int weeklyHour;

    PartTimeEmployee(String email, String name, 
                     int employeeId, int weeklyHour) {
        super(email, name, employeeId);
        this.wheeklyHour = weeklyHour;
    }
}

// Class instantiation in Java

PartTimeEmployee john = 
    new PartTimeEmployee("john.doe@vaticle.com",
                         "John Doe", 346523, 35);

However, relational databases are unable to natively model objects due to their lack of expressivity.

-- Table inheritance in SQL

CREATE TABLE Users (
    id SERIAL PRIMARY KEY,
    email TEXT NOT NULL,
    name TEXT NOT NULL,
    UNIQUE (email)
);

CREATE TABLE Employees (
    id INTEGER NOT NULL,
    employeeId INTEGER NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (id) REFERENCES Users(id),
    UNIQUE (employeeId)
);

CREATE TABLE PartTimeEmployee (
    id INTEGER NOT NULL,
    weeklyHour INTEGER NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (id) REFERENCES Employees(id)
);

-- Data inserting for extended tables in SQL

DO $$
DECLARE
    inserted_user_id INTEGER;
BEGIN
    INSERT INTO Users (id, email, name)
    VALUES (DEFAULT, "john.doe@vaticle.com", "John Doe")
    RETURNING id INTO inserted_user_id;

    INSERT INTO Employees (inserted_user_id, 346523)

    INSERT INTO PartTimeEmployees (inserted_user_id, 35)
COMMIT;
END $$;

-- Data retrieval for all Users and extended tables in SQL

SELECT
    Users.id AS id,
    Users.email AS email,
    Users.name AS name,   
    null AS employeeId, 
    null AS weeklyHours,
    "user" AS userType 
FROM Users 
WHERE NOT EXISTS (
    SELECT id FROM Employees WHERE Users.id = Employees.id
) 
UNION ALL 
SELECT
    Users.id AS id, 
    Users.email AS email,
    Users.name AS name,
    employeeId,
    null AS weeklyHours,
    "employee" AS userType
FROM Users 
INNER JOIN Employees ON Users.id = Employees.id
WHERE NOT EXISTS (
    SELECT Employees.id 
    FROM PartTimeEmployee 
    WHERE Employees.id = PartTimeEmployee.id
) 
UNION ALL
SELECT 
    Users.id AS id,
    Users.email AS email,
    Users.name AS name,
    employeeId,
    weeklyHours,
    "partTimeEmployee" AS userType
FROM Users
INNER JOIN Employees ON Users.id = Employees.id
INNER JOIN PartTimeEmployee ON Employees.id = PartTimeEmployee.id

This fundamental incompatibility between object and relational models has become one of the biggest challenges in database engineering. Because of object-relational mismatch, relational databases have been unable to evolve alongside programming languages.

NoSQL eliminated the schema at the cost of declarative data retrieval. The limitations of relational databases led to the emergence of NoSQL databases, particularly document and graph databases. These databases eliminated the predefined schema, making data insertion trivial, but this comes with the cost of complicating retrieval. Without a schema, structural metadata must be stored as data, hardcoded into queries, or modeled in a secondary data store. This forces engineers to access their data imperatively, as the database does not have the context to correctly interpret declarative polymorphic queries.

Document databases are optimized to store hierarchical data, but this breaks down when attempting to model highly interconnected data. To do so, engineers are required to choose between using performance-intensive foreign ID references or duplicating data across documents without native consistency control.

// Retrieval of polymorphic resources in MongoDB

db.resource_ownerships.aggregate( [
  {
    $lookup:
    {
        from: "resources",
        localField: "resource",
        foreignField: "_id",
        as: "resource"
    }
  },
  {
    $unwind:
    {
        path: "$resource"
    }
  },
  {
    $lookup:
    {
        from: "users",
        localField: "owner",
        foreignField: "_id",
        as: "owner"
    }
  },
  {
    $unwind:
    {
        path: "$owner"
    }
  },
  {
    $unwind:
    {
        path: "$owner.emails"
    }
  },
  {
    $addFields:
    {
      resource_id: {
        $switch: {
            branches: [
            {
              case: { 
                $eq: ["$resource.resource_type", "file"]
              }, 
              then: "$resource.path" 
            },
            {
              case: { 
                $eq: ["$resource.resource_type", "directory"]
              }, 
              then: "$resource.path" 
            },
            {
              case: { 
                $eq: ["$resource.resource_type", "commit"]
              }, 
              then: "$resource.hash" 
            },
            {
              case: { 
                $eq: ["$resource.resource_type", "repository"]
              }, 
              then: "$resource.name" 
            },
            {
              case: { 
                $eq: ["$resource.resource_type", "table"]
              }, 
              then: "$resource.name" 
            },
            {
              case: { 
                $eq: ["$resource.resource_type", "database"]
              }, 
              then: "$resource.name" 
            }
          ]
        }
      }
    }
  },
  {
      $project: {
          _id: false,
          email: "$owner.emails",
          resource_type: "$resource.resource_type",
          id: "$resource_id"
      }
  }
] )

Meanwhile, graph databases excel at linking highly interconnected data, but are severely limited by the implementation of relations as edges. This means that more complex types like n-ary relations, nested relations, and variadic relations are impossible to express without reifying the data model.

// Retrieval of polymorphic resources in Neo4j's Cypher
MATCH
    (user:User)-[:OWNS]->(rsrc:Resource)
WITH
    rsrc,
    [user.primary_email] + user.alias_emails AS emails,
    labels(rsrc) AS resource_types,
    keys(rsrc) AS properties
UNWIND emails AS email
UNWIND resource_types AS resource_type
WITH
    rsrc, email, resource_type, properties,
    {
        File: "path",
        Directory: "path",
        Commit: "hash",
        Repository: "name",
        Table: "name",
        Database: "name"
    } AS id_type_map
WHERE resource_type IN keys(id_type_map)
AND id_type_map[resource_type] IN properties
RETURN email,
       resource_type,
       rsrc[id_type_map[resource_type]] AS id

ORMs work around the fundamental problem by trading off performance. Engineers have attempted to work around the mismatch problem, building layers of abstraction over databases in an attempt to give them the expressivity they were never designed with. This requires engineers to non-natively manage structural metadata, leading to the widespread use of ORMs. They offer object-oriented APIs for managing and storing data, but because of the imperfect translation to the underlying models, they can never express the full range of queries that can be written natively. This results in limited capabilities and poor query optimization, while introducing an additional layer of complexity and overhead to database architecture.

Databases have been left far behind programming languages in safety and expressivity.

Current paradigms are unable to natively handle the data abstractions that we so easily take for granted in programming languages. TypeDB aims to solve this problem by providing a database that natively understands complex object-oriented data structures and supports abstraction, inheritance, and polymorphism. By integrating the benefits of strong typing and query flexibility, TypeDB simplifies data access and eliminates the need for manual mapping.

What defines a polymorphic database?

There are three forms of polymorphism in computer science. In order to be fully polymorphic, a database must implement the three fundamental kinds of polymorphism possible in object-oriented programming:

Inheritance Polymorphism: The ability to define a class hierarchy where children inherit properties from their parents, and to interpret queries that operate on instances of a class and all its children.
Interface Polymorphism: The ability to define properties as interfaces that classes can implement independently of their parents, and to interpret queries that operate on instances of all classes that implement a specified interface.
Parametric Polymorphism: The ability to interpret queries that are abstract and able to operate on instances of any class supplied as a parameter to the query.

To be fully polymorphic, a database has to implement three systems:

Variablizable Language: A query language that is expressive enough to variablize classes, either explicitly or implicitly. This is required to describe interface and parametric polymorphism, and so declaratively capture the intent of the query.
Polymorphic Schema: A schema or equivalent metadata store containing the semantic context for interpreting the query’s intent. It must contain the class and interface definitions, the class hierarchy, and the interface implementations.
Inference Engine: An inference engine for reducing the declarative query into an imperative form before being sent to the query planner. This is based on the structure of the query combined with the semantic context provided by the schema.

Current databases do not implement any form of polymorphism
Relational schemas define tables and columns as direct analogs of classes and their properties. As columns cannot be independently implemented by multiple tables, relational databases cannot natively implement interface polymorphism. Tables and columns also cannot be variablized in SQL, meaning that SQL cannot express interface and parametric polymorphism.
Document and graph databases can define a limited number of constraints on inserted data, but this does not have the expressivity of a hierarchical schema built with classes and interfaces. As a result, these databases cannot natively implement all three types of polymorphism.

A fully polymorphic database implements all three of these requirements, that is a) a polymorphic query language, b) polymorphic schema, and c) inference engine. It is able to express all three fundamental kinds of polymorphism possible in object-oriented programming, which can be combined to yield unique and powerful features, not possible with any one kind alone. These include:

the ability to write polymorphic queries in near-natural language,
to construct polymorphic views that extend themselves when the schema is extended, and
to perform polymorphic deductions that generate new data using rules.

A fully polymorphic database also displays model polymorphism - that is the ability to natively model data from relational, document, graph, and other database paradigms.

What makes TypeDB the polymorphic database?

TypeDB is a polymorphic database with a strongly typed schema for defining inheritance and interfaces, a variablizable query language for composing declarative polymorphic queries, and a type inference engine for resolving queries against the schema. TypeDB schemas implement the polymorphic entity-relation-attribute (PERA) model for data, an extension of Chen’s entity-relationship (ER) model. The ER model is the most widely used tool for building conceptual data models prior to translating them into the logical bounds of a database paradigm.

A conceptual data model built on a type-theoretic language

TypeDB implements the PERA model as its database paradigm, which allows schemas to be built directly from the conceptual models that people use to represent domains and their data. Schemas and queries for TypeDB are described using TypeQL, its type-theoretic query language. By combining a strongly typed schema, a fully variablizable query language, and a type inference engine, TypeDB implements all three fundamental kinds of polymorphism, making it a truly polymorphic database.

Types are defined in a hierarchy

The PERA model is described by types, defined in the schema as templates for data instances and analogous to classes in OOP. Each user-defined type extends one of the three root types: entity, relation, and attribute, or a previously user-defined type.

Entities represent independent concepts.
Relations represent concepts that depend on one or more roles that can be played by entities and other relations.
Attributes represent properties that entities and relations can have, and they are defined with a declared value type and instantiated with a particular value.

Entities, relations, and attributes can all be either concrete or abstract, and roles in relations can be overridden by their subtypes.

#Schema definition of the user-employee object model in TypeQL
#TypeQL is TypeDB's query language

define

id sub attribute, abstract, value string;
email sub id;
name sub id;
path sub id;

user sub entity;
admin sub user;
user-group sub entity;
resource sub entity, abstract;
file sub resource;

ownership sub relation, abstract,
    relates owned,
    relates owner;
group-ownership sub ownership,
    relates group as owned;
resource-ownership sub ownership,
    relates resource as owned;

Behaviors are implemented and inherited

Once entity, relation, and attribute type hierarchies have been defined, interfaces are created by declaring the attributes that entities and relations own, and the roles they play in relations. Declared attributes owned and roles played are independent of each other, and multiple entity and relation types can own the same attribute or play the same role. The attributes a type owns and the roles it plays are inherited by its subtypes, and can be overridden to control the specificity of these properties.

#Attribute ownership in an entity 
#and entity role definition in a relation in TypeQL

define

user owns email,
    plays resource-ownership:owner;
admin plays group-ownership:owner;
user-group owns name,
    plays group-ownership:group,
    plays resouce-ownership:owner;
resource owns id,
    plays resource-ownership:resource;
file owns path as id;

Data is semantically validated

With the type hierarchies and interfaces defined in the schema, data can be instantiated with an insert query. Data instances and types are defined by variables using a $variable-name that exists in the scope of the query and can be reused to describe complex data patterns. Relations are defined with a tuple of roleplayers and the roles they play. Insert queries undergo semantic validation against the schema, ensuring that the inserted data patterns are valid. Queries that would insert data not allowed by the schema are rejected.

#Compound insert statement that efficiently
#populates users, group definitions, assets 
#and various ownership relations into 
#a trivial IAM database in TypeDB.

insert

$naomi isa admin, has email "naomi@vaticle.com";
$amos isa user, has email "amos@vaticle.com";
$engineers isa user-group, has name "engineers";
$benchmark isa file, has path "/amos/benchmark-results.xlsx";
$roadmap isa file, has path "/vaticle/feature-roadmap.pdf";

(group: $engineers, owner: $naomi) isa group-ownership;
(resource: $benchmark, owner: $amos) isa resource-ownership;
(resource: $roadmap, owner: $engineers) isa resource-ownership;

Data is queried polymorphically

Data is queried with high-level patterns, in which any element can be variablized. Queries are analyzed by the type inference engine before going to the query planner. It resolves polymorphism by identifying possible types that could fit patterns as defined by the schema, and queries return instances of all those types:

Querying a supertype returns instances of subtypes that inherit from it (i.e. inheritance polymorphism).
Querying an interface returns instances of types that implement it (i.e. interface polymorphism)
Querying a variablized type parametrically returns instances of all types that match the pattern (i.e. parametric polymorphism)

#An efficient 6-line polymorphic query in TypeDB 
#retrieves all instances of ownership relations 
#(i.e. group-ownership and resource-ownership)
#and their related data.

match
(owned: $object, owner: $owner) isa! $ownership-type;
fetch
$ownership;
$object: id;
$owner: id;

# Results:
[{
    "ownership-type": { "root": "relation", "label": "group-ownership" },
    "object": {
        "type": { "root": "entity", "label": "user-group" },
        "id": [
            { "value": "engineers", "value_type": "string",
              "type": { "root": "attribute", "label": "name" } }
        ]
    },
    "owner": {
        "type": { "root": "entity", "label": "admin" },
        "id": [
            { "value": "naomi@vaticle.com", "value_type": "string",
              "type": { "root": "attribute", "label": "email" } }
        ]
    }
},
{
    "ownership-type": { "root": "relation", "label": "resource-ownership" },
    "object": {
        "type": { "root": "entity", "label": "file" },
        "id": [
            { "value": "/amos/benchmark-results.xlsx",
              "value_type": "string", 
              "type": { "root": "attribute", "label": "path" }
            }
        ]
    },
    "owner": {
        "type": { "root": "entity", "label": "user" },
        "id": [
            { "value": "amos@vaticle.com", "value_type": "string", 
              "type": { "root": "attribute", "label": "email" } }
        ]
    }
},
{
    "ownership-type": { "root": "relation", "label": "resource-ownership" },
    "object": {
        "type": { "root": "entity", "label": "file" },
        "id": [
            { "value": "/vaticle/feature-roadmap.pdf", 
              "value_type": "string", 
              "type": { "root": "attribute", "label": "path" }
            }
        ]
    },
    "owner": {
        "type": { "root": "entity", "label": "user-group" },
        "id": [
            { "value": "engineers", "value_type": "string", 
              "type": { "root": "attribute", "label": "name" } }
        ]
    }
}]

How does TypeDB impact database engineering?

A unified way of working with data in the database and application. TypeDB provides a database that natively models and implements complex object-oriented data structures like abstraction, inheritance, and polymorphism. With these capabilities, TypeDB enables engineers to work with flexible and adaptable data models, making it easier to manage, query, and reason over complex data structures.

By integrating a conceptual data model, a strong subtyping system, a symbolic reasoning engine, and a type-theoretic language, TypeDB has redefined database architecture and achieved the native expressivity required for modern applications.

// Class inheritance in Java of a user-employee model 

class User {
    String email;
    String name;

    User(String email, String name) {
        this.name = name;
        this.email = email;
    }
}

class Employee extends User {
    int employeeId;

    Employee(String email, String name, int employeeId) {
        super(email, name);
        this.employeeId = employeeId;
    }
}

class PartTimeEmployee extends Employee {
    int weeklyHour;

    PartTimeEmployee(String email, String name, 
                     int employeeId, int weeklyHour) {
        super(email, name, employeeId);
        this.wheeklyHour = weeklyHour;
    }
}

// Class instantiation in Java

PartTimeEmployee john = 
    new PartTimeEmployee("john.doe@vaticle.com",
                         "John Doe", 346523, 35);

#the TypeQL schema definition for the user-employee model

define

email sub attribute, value string;
name sub attribute, value string;
emloyee-id sub attribute, value long;
weekly-hour sub attribute, value long;

user sub entity,
    owns name,
    owns email;

employee sub user,
    owns employee-id;

part-time-employee sub employee,
    owns weekly-hour;

insert $john isa part-time-employee,
    has email "john.doe@vaticle.com", 
    has name "John Doe",
    has employee-id 346523, 
    has weekly-hour 35;

Moreover, as a truly polymorphic database, TypeDB offers a number of unique capabilities not natively attainable with other database paradigms:

Object Model Parity: TypeDB’s type-theoretic schemas allow for perfect parity with object models. Constructs that can be challenging to natively model in other databases are simple and intuitive in TypeDB. Utilize type hierarchies, abstract types, multivalued attributes, n-ary relations, nested relations, variadic relations, and complex cardinality constraints all without normalization, reification, or any other process that warps the conceptual model.
Continuous Extensibility: Types can be polymorphically queried, so the results of queries automatically extend to include new valid types that are added to the schema after the query is written. This minimizes the need to maintain and update queries when the schema is intended, so long as the semantic intent of the query remains the same. With careful design of the initial schema to ensure extensibility, migrations can be entirely avoided.
Logical Abstractions: TypeDB allows for logical abstractions by defining rules for the native symbolic reasoning engine. They are written using the same patterns as queries and resolved against the schema, combining the flexibility of polymorphism with the power of symbolic reasoning. By employing sequential and recursive triggering of rules, extremely complex logical behaviors can arise from rules that are individually very simple, mirroring the true semantic logic of complex data domains.
Data Consistency: When utilizing symbolic reasoning, new fact generation occurs at query time, ensuring that generated data is never stale. By using rules to govern data dependencies within the database, all inferred data can be made to have a single source of truth, preventing data conflicts from ever occurring. This ensures that the database is always in a consistent and current state, preventing the need for precomputation cycles.
Unified Data Models: The high-level conceptual data model means that schemas in relational, document, and graph databases can be translated with no loss of information, and then enhanced with TypeDB’s unique modeling constructs. This allows for easy transfer of data from other databases, as part of migrations or a multi-database architecture.
Near-Natural Language: Due to the declarative nature of TypeQL and its careful syntax design, schemas and queries read close to natural language. This allows engineers to state the intent of their queries at the highest level, without having to use imperative language to describe low-level data structure. Because of this, engineers and domain experts can understand the intent of queries, even with no experience of writing them.

Though it is possible to implement these features in other databases by building a layer of abstraction over the database, the lack of native support means that engineers have to build, maintain, and debug these solutions themselves. Such solutions are also poorly optimized because they cannot take advantage of direct integration with the database. With TypeDB, all of these features are built-in, robust, and performant.

Welcome to the dawn of the polymorphic database

TypeDB enables engineers to work with flexible and adaptable data models, making it easier to manage, query, and reason over complex data structures. By integrating a conceptual data model, a strong subtyping system, a symbolic reasoning engine, and a type-theoretic language, TypeDB has redefined database architecture and achieved the native expressivity required for modern applications.

To learn more about TypeDB and its features, please visit https://typedb.com and https://typedb.com/features

To download TypeDB, please visit https://typedb.com/deploy

To read TypeDB's documentation, please visit https://typedb.com/docs

A New Era for TypeDB

Skip Everling — Mon, 10 Jul 2023 22:49:53 +0000

When we started building TypeDB, we saw a continuously growing complexity of data in modern applications. Modern programming languages have evolved by introducing powerful abstractions and constructs to express more complex logic – JavaScript is succeeded by TypeScript, Java by Kotlin, C/C++ by Rust, and Haskell emerging as the leader of functional languages. Modern languages all have a stronger and more expressive type system.

However, when we look at the evolution of database technologies since relational algebra and SQL, even though there has been incredible progress in performance and operational capabilities in the past 40 years, databases have yet to provide more powerful abstractions to express more advanced logic. In fact, graph, document, key-value, wide-column, and every other NoSQL database provide lower-level and more primitive data structures for us to express our models and queries. This is a huge problem for future applications, as they will need to work with more complex datasets and interrogate their data more intelligently.

We built TypeDB & TypeQL to provide much more powerful abstractions in the database language, allowing you to tackle the next order of complexity in future applications. For the first time, TypeDB brings to the database the power of a strong type system , the simplicity of a composable language, and the intelligence of symbolic reasoning to infer data.

This year, we’re launching typedb.com to help you understand our paradigm and unique features, and to deliver a brand new and enhanced documentation portal. We are also incredibly excited to invite you to the very first webinar series on TypeDB Fundamentals, happening in just 3 weeks!

We see the problem of data complexity in many modern applications, especially those serving intelligent operations.

In Cybersecurity, Cyber Threat Intelligence and Identity Access Management solutions struggle to keep up with rapid evolution of data and the amount of hidden patterns. In Platform Engineering, Internal Developer Platforms and Continuous Delivery systems struggle with the unknown consequences of change and fragmentation of data. In Knowledge Engineering, Drug Discovery and Risk Management solutions find that their biggest hurdle is connecting independent datasets in a way that makes it easy to derive hidden and implicit connections. Virtual Representations, such as those found in Robotics, Digital Twins, and Gaming, struggle with modeling real-world details in a virtual environment.

This year, we’ll be sharing with you the research we’ve done on applications of TypeDB in these advanced domains, starting with our first webinar series on our new TypeDB Use Cases, happening 4 weeks from now!

TypeDB Cloud Alpha is here!

After a whole year of engineering, we are finally ready to invite you to try out TypeDB Cloud! You can now automatically deploy TypeDB in the US and Europe, on Google Cloud and Amazon AWS. More regions across the globe will be coming soon, as well as the option for Microsoft Azure. At this alpha stage of TypeDB Cloud, we’d love to hear your feedback on how TypeDB Cloud meets your expectations, and you’ll have the opportunity to contribute to our development roadmap!

Join the TypeDB Cloud waitlist!

Finally, TypeDB 2.18 & 2.19 are released with major updates!

We’ve had 2 major releases in the past month: 2.18 and 2.19. We introduced new functionalities to perform arithmetic operations in TypeQL. We’ve significantly improved import/export of schema & data together. We replaced our storage engine from RocksDB to SpeeDB and boosting performance. And finally, we now natively support ARM processors for both Mac and Linux, which means you can run TypeDB on Apple silicon chips as well as Raspberry Pis!

There are a lot more major updates coming in the next few months: a new and highly-performant TypeDB Rust driver – and every other driver wrapping the Rust driver binary, new TypeQL capabilities to fetch all attributes of entities and relations as part of answers, optional query patterns in TypeQL, native JSON response format, and many more! For now, we hope you enjoy the new TypeDB 2.19!

Deploy the new TypeDB

How Roche Discovered Novel Potential Gene Targets with TypeDB

daniel crowe — Thu, 10 Jun 2021 16:54:32 +0000

How a type system brings speed and novelty to the drug discovery pipeline

Debrief from a Vaticle Community talk — featuring David Dylus, Scientist, Systems Biology, at Roche. This talk was delivered virtually at Orbit 2021 in April.

Central to drug discovery is the search for targets that are important in disease mechanisms. However, currently, all known targets have been slowly tried and tested. In this project, David and his team designed a rule system to infer and find hidden connections between targets and diseases.

In the story to follow, David presents how his team at Roche was able to identify potential novel targets that were not identified by Open Targets as highly ranked. This was made possible with TypeDB, which his team used to store the relevant data and then find underlying biological evidence for those new targets.

What datasets were used?

For this project, three datasets were used: STRING, Oma, and DisGeNET.

STRING is a database of known and predicted protein-protein interactions. The interactions include direct (physical) and indirect (functional) associations; they stem from computational predictions, knowledge transfer between organisms, and interactions aggregated from other (primary) databases. This includes not only literature but also experimental evidence for proteins interacting with other proteins. This means that we can search for proteins that have only an experimentally validated protein-protein-interaction.

Oma was used to insert gene families, parallax genes, i.e. similar genes that have been conserved in function and are duplicates on the genome, potentially having a similar function to each other.

Finally, DisGeNET was used to provide variant information, which allowed them to link mutations to genes: for example, if you have a mutation on your genome, if that mutation is linked to a gene, and if that gene is linked to a disease, we can association the disease to that mutation. This database was also mentioned by Tomás in his Orbit 2021 talk [Computational Future of Biology].

This then leads us to ask a question such as:

Do people that have this mutation, also have some type of prevalence for a specific disease?

To answer this, we should check how closely the specific mutation is to the gene and then assign that this variant somehow modulates that gene. This would explain why we see this type of disease phenotype.

How to Model and Query for Insights

To start, the team looked at existing targets on the Open Targets database and selected those already ranked highly and known to have a high association score— due to internal Roche IP, unfortunately, they cannot mention which ones specifically; they have been renamed for understanding.

David called the highly ranked targets taken from Open Targets billionDollarTarget and bestTarget, which overall have a high association score, in other words, they are strongly linked to the disease that David's team is interested in. Below we’ll see how TypeDB can be used to find targets that don’t rank highly on Open Targets, but are still indirectly modulating the disease and are therefore potentially high-value targets to explore.

For this purpose, David built out a set of rules and schema in TypeQL. Below is just a very small excerpt of how such data can be modelled — taken from BioGrakn-Covid, a Vaticle community-led project by Konrad Mysliwiec (Data Science Software Engineer, Roche). Note that this is a selected schema; the full schema can be found within the BioGrakn-Covid schema file.

define
gene sub fully-formed-anatomical-structure,    
  owns gene-symbol,       
  owns gene-name,      
  plays gene-disease-association:associated-gene;
disease sub pathological-function,    
  owns disease-name,    
  owns disease-id,    
  owns disease-type,    
  plays gene-disease-association:associated-disease;
protein sub chemical,    
  owns uniprot-id,    
  owns uniprot-entry-name,    
  owns uniprot-symbol,    
  owns uniprot-name,    
  owns ensembl-protein-stable-id,      
  owns function-description,    
  plays protein-disease-association:associated-protein;
protein-disease-association sub relation,    
  relates associated-protein,    
  relates associated-disease;
gene-disease-association sub relation, 
  owns disgenet-score,    
  relates associated-gene,    
  relates associated-disease;

With the right schema, rules and data inserted, we can write the first query. The relation below is one that David’s team called gene-disease-inference, with an attribute order:1 to denote that it’s a direct relation. The query looks like this:

match
$d isa disease, has disease-name "Disease";
$r ($gene, $d) isa gene-disease-inference, has order 1;
get $r, $d, $gene;

The result is below, we can see that the billionDollarTarget, the bestTarget, and the youWillNeverGuessTarget are linked to Disease. We also see that these three targets are of order: 1, which indicates a direct and previously known association between the disease and the genes. However, the goal is to find novel targets.

To do this, they write the query shown below. This looks for diseases and genes connected through a gene-disease-inference relation with order: 2, but explicitly excludes those that already are connected with a gene-disease-inference relation with order:1:

match
$d isa disease, has disease-name "Disease";
$r ($gene, $d) isa gene-disease-inference, has order 2;
not {($gene, $d) isa gene-disease-inference, has order 1;};
get $r, $d, $gene;

This query returns a completely different list of genes: whatCouldIBeTarget, awesomeTarget, and thatTarget. All these are targets connected to Disease through a gene-disease-inference with order:2.

If you are not familiar with TypeDB Workbase, you can right-click one of the inferred relations and select “Explain” in the dropdown. This will explain those inferences and tell you how these targets are connected to our disease via typed roles, played by the targets.

If we explain the inferred relation that links deadTarget, we see that this target is part of the same gene family as youWillNeverGuessTarget with order: 1. This inference was made possible through a rule, which allows us to infer new data based on existing data. In this case, we found a previously unknown indirect interaction between two targets.

The logic behind the rule that gives this inference breaks down as follows:

When:

a gene target is linked to a disease
and that target is also in the same gene family as another target already identified as having a strong association to a disease

Then:

this gene target and the disease should connected through a gene-disease-inference relation

For the other novel targets, awesomeTarget and bestTarget, we see that those inferences are based on a protein-to-protein interaction, which connects to the whatCouldIBeTarget. If we explain that relation, we see that it is connected to the billionDollarTarget via a gene-disease-association, potentially sharing the same variant to the disease.

Even though awesomeTarget and thatTarget appear in the Open Targets database for the disease of interest, they ranked very low. That means they had some link to that disease, but not a strong one. TypeDB uncovered new evidence that suggests those targets could be higher ranked.

This is how David’s team at Roche was able to leverage TypeDB’s reasoning engine to find novel targets that might have been missed using standard approaches or more direct approaches.

That said, biology is a very complicated field that is constantly evolving. Data sets that have been true in the past might not be true today. We are constantly dealing with new confounders, different methodologies, the noise that is inherent in biology. The goal is to find novel ways of modulating a disease with strong biological evidence that will work.

Having found a novel target does not necessarily mean that this is now a solution or ready for trials. However, it is a great hypothesis to start digging into its efficacy to modulate a specific disease, whether to find a cure or provide better therapeutics to a patient.

Where can we go from here?

Instead of targeting a single protein, more advanced targeting can be done by integrating additional information such as protein complexes and pathways. For example, we could look for several genes that are part of the same pathway. If a drug cannot modulate a single target enough to impose a positive change in the state of a patient, then we might consider targeting multiple points on the same pathway.

David also mentioned he considered extending the rules to, for example, find higher-order relations, to enable the examination of third, fourth or fifth order connections to the specific disease. There is also room for expanding beyond protein-protein interactions and incorporate very specific query constraints. For instance, we could filter that we want genes X and Y to be part of the same pathway, expressed in the same cell type, shown to be up or down-regulated in disease expression, etc. In this way, like boundary conditions, we can increase our target prioritization and make this highly valuable to our process.

A special thank you to David for his work, contribution to the community and for always bringing joy into his work.

All slides used with permission. You can find the full presentation on the Vaticle YouTube channel here.