🔗TreeLDR

This page contains documentation for TreeLDR v0.1.0. The library has since undergone significant updates and is now at version 0.2. We're actively working to update the documentation — thank you for your patience!

TreeLDR is a schema definition language that aims at describing both the structure and semantics of the defined schema in a comprehensible way. It lies at the intersection between RDF (and its various schema definition ontologies such as OWL) and structure-oriented schema definition frameworks such as JSON Schema or IPLD.

To try out TreeLDR, check out our Quickstart guide:

TreeLDR Quickstart

• A backend server, written in Rust, managing users, the publication and access to blog posts. We will consider a federation where multiple backend servers can also communicate between each other in a decentralized manner;

• A database server, storing users and posts information;

• A client application, written in TypeScript, connecting to the backend server, accessing and displaying posts to some user.

All those components know the concept of user and post but may have a different inner data representation for them. For instance:

• The backend server represents users and posts in memory following the layout of their respective Rust type definition

• The database server stores users and posts in a SQL table.

In addition, they must agree on a data representation to communicate with each other. For instance:

• The backend server may communicate with the database using SQL queries;

• Servers may communicate with each other using JSON-LD;

• Clients may communicate with a server using JSON, regulated by a JSON Schema.

This example shows how even a simple distributed application introduces a lot of redundancies in data schema definitions. Here each concept (user and post) require at least 5 different representations throughout the different components, and conversion procedures to go from one representation to the other.

TreeLDR can solve this issue by providing a single language to define common concepts (types) and shared data representations (layouts) that can then be exported into various other languages and schema definitions. For instance here is a simple TreeLDR schema definition for our blogging application:

use <http://www.w3.org/2001/XMLSchema#> as xs;

type User {
	name: xs:string,
	birthDate: xs:date
}

type BlogPost {
	title: required xs:string,
	content: required xs:string
}

The end goal of TreeLDR is to use this unique definition to generate every other schema definition in our distributed application. In our example this means:

• Rust type definitions for User and BlogPost in the backend server,

• the necessary SQL table definitions for the database server,

• TypeScript type definitions for User and BlogPost in the client application,

• a JSON-LD context defining User and BlogPost in the JSON-LD documents exchanged between the servers,

• a JSON Schema constraining the JSON documents exchanged between the client and server.

Here is the Rust code generated from the definition above, that we won't have to write ourselves thanks to TreeLDR.

pub mod xs {
	pub type String = ::std::alloc::String;
	pub type Date = ::chrono::Date<::chrono::offset::Utc>;
}

struct User {
	name: Option<xs::String>,
	birth_date: Option<xs::Date>
}

struct BlogPost {
	title: xs::String,
	content: xs::String
}

Besides the schema itself, by understanding the semantics attached to the schema TreeLDR can automatically generate boiler plate code for common tasks such as serialization/deserialization, conversions between different representations, etc.