A scalable platform for building linked data applications.

General documentation for Trellis is available on the project wiki.

A mailing list is available to anyone who is interested in using, contributing to or simply learning more about Trellis.

The fastest way to get started with Trellis is to download the latest release and follow these installation instructions.

Trellis has been designed with four primary goals:

• Scalability
• Long-term durability of content
• Modularity
• Adherence to existing web standards

Trellis has been built from the ground up to support horizontal scalability. While it is possible to run Trellis on a single machine, scaling out across a cluster is well-defined and supported. Trellis is eventually consistent, which is to say that many operations run asynchronously. While this makes the system very responsive, it also means that clients cannot always expect operations to be atomic. In general, per-resource operations are atomic; operations that cause other resources to change tend to be handled asynchronously.

Data integrity is vitally important for content that is stored for years and decades. Trellis makes it possible to retrieve the state of any resource at any, arbitrary point in time. This also means that nothing is ever truly deleted. For every operation that changes a resource, there is a full audit log available through standard LDP mechanisms. This audit log lists who made what change and when that change was made.

The overall code base for Trellis is small, and it is divided up into even smaller modules. This simplifies maintenance and it also makes it easy to customize individual components as needed. Trellis has also been designed to fully support OSGi deployment.

The Trellis project has selected to conform to a collection of well-defined and broadly used specifications because doing so provides a solid and well-understood foundation for interacting with the software. This also makes the Trellis API stable and consistent.

Because Trellis is built on top of LDP, clients that interact with it tend to use a lot of RDF (e.g. JSON-LD). Trellis enforces only a very minimal set of restrictions on what RDF is allowable: if LDP prohibits it, Trellis does not allow it, but otherwise, pretty much anything goes. You can use any RDF vocabulary; you can store binaries of any type.

Any time a resource is created, modified or deleted, a notification is made available, making it easy to use an integration framework to connect Trellis to external applications. The notifications provide enough information to make informed routing decisions.

Trellis is an HTTP/1.1 server, which complies with the following specifications:

• W3C LDP Server
• W3C Activity Streams 2.0
• Solid WebAC (Authorization and Access Control)
• RFC 7089 (HTTP Framework for Time-Based Access to Resource States -- Memento)
• RFC 3230 (Instance Digests in HTTP)

All source code is open source and licensed as Apache 2. Contributions are welcome.

This vocabulary defines the Trellis-specific RDF terms. A DOAP file describes the Trellis project in a machine-readable format.

This repository contains the core abstractions and interfaces for Trellis along with a number of default service implementations. It contains a reference implementation that uses a persistence layer based on a triplestore or local dataset. In addition, below is a list of other known implementations.

• Rosid: A Kafka-based application that uses file-based persistence.

• Commons-RDF -- for RDF abstractions
• Jena -- for RDF I/O processing
• Jackson -- for JSON processing

• py-ldnlib A Python3 library for linked data notifications
• static-ldp A PHP application that serves static files as LDP resources

• Trellis is written in Java and requires at least Java 8. It can be built with Gradle.

$ ./gradlew install