LinkedDataHub 6: the application is data

LinkedDataHub 6 is out, and the latest release is 6.2.2.

Version 6 brings a redesigned interface and changes to how applications are packaged, deployed and maintained. It also brings LinkedDataHub closer to the RDF-native application architecture I have been working on for years.

An application should be defined by data, not by custom code.

In LinkedDataHub, an application consists of RDF documents defining its domain model, forms, views, queries, charts, access rules and stylesheet imports. The same Linked Data interfaces used for ordinary RDF documents also manage application definitions. You deploy a whole application by pushing a directory of RDF documents and the files they use, and an LLM agent can write and maintain it.

Each section below ends with something you can run or look at, and with the chapter of First Principles of the Web that derives it. That is my book: it works out from first principles the one architecture that is of the web rather than merely on it, and finds it was standardized decades ago as RDF, SPARQL, XSLT and CSS.

Applications as data

CMSs, CRMs and ERPs have more in common than their separate implementations suggest. Much of their functionality consists of generic operations over domain-specific data models. RDF and ontologies express those models as data; Linked Data and SPARQL provide a common way to read and modify them. LinkedDataHub extends that approach to application definitions.

An application package contains RDF documents such as ontologies, constructors, constraints and queries. It can also include XSLT stylesheets to extend the default rendering and interaction.

In version 6, the ldh CLI deploys an application from the filesystem. ldh push maps a directory to the corresponding document tree. ldh packages installs and removes packages, importing their ontologies and stylesheets into the dataspace without a separate application build.

Try it: the Northwind Traders source is a directory of RDF documents. Push it, or open the running app. The directory is the whole app.
Derived in: Chapter 21, Generic Software; Chapter 17, The Derived Stack.

The page is the graph

Every LinkedDataHub document is a named graph. Its XHTML representation contains RDFa asserting the same graph served from its URL as RDF, including the document metadata. The page people read and the data machines read come from the same source, so they cannot drift apart.

Try it: request any document as text/turtle, extract the RDFa from its page, and compare the statements.
Derived in: Chapter 22, The Result.

One rendering architecture for server and browser

In First Principles of the Web, a page read is factored as read = present ∘ arrange ∘ select. LinkedDataHub uses SPARQL to select data from the RDF dataset and XSLT 3.0 to transform the result into XHTML.

The same stylesheets run on the server and in the browser. SaxonJS 3 and IXSL handle browser interaction, including events, through XSLT templates. There is no separate JavaScript implementation of the interface. Package stylesheets are compiled into the browser stylesheet.

XSLT provides template matching, imports and extensibility, which are useful for a generic RDF interface. Version 6 continues to use it throughout the UI.

Derived in: Chapter 4, The Factorization; Chapter 6, From Graph to Tree.

A redesigned interface

The interface has been redesigned. Bootstrap 2 has been replaced by a design system built into the platform, with light and dark modes and layouts that work on phones.

The new interface is still rendered with XSLT, not a separate JavaScript framework. It works with arbitrary RDF data. Applications can override templates where they need different presentation or interaction.

History is git

With versioning enabled, each write creates a commit in a GitHub repository. Documents are stored as sorted N-Triples, and commits use the WebID of the human or AI agent making the change as the author. Git provides the version history.

The history is exposed through the Memento protocol (RFC 7089). Versioned documents have a TimeMap, a TimeGate and addressable earlier versions. The UI supports comparing and restoring them.

An update to an existing document has to say which version it is editing. This prevents one client from silently overwriting another’s changes, including when humans and agents work on the same dataspace.

Derived in: Chapter 7, The Write Side.

Agents use the same API humans do

An LLM agent should not need to generate a custom codebase for every application. If application definitions are data, the agent can work directly with the domain model and those definitions.

Each dataspace serves /AGENTS.md with instructions for agents. The ldh CLI manages applications and documents, and a Claude Code plugin makes those operations available to coding agents. An optional assistant can turn a natural-language request into a plan for review and execution.

Agents use the same Linked Data interfaces as human users, rather than a separate agent API. Access control and versioning apply to both.

Derived in: Chapter 24, The Agent Era.

A simpler stack

A single Apache Jena Fuseki service now hosts the stores for all dataspaces, replacing separate admin and end-user servers. nginx queues bursts of page requests and limits external SPARQL clients separately from requests made by the platform. The public Linked Data interface is unchanged.

Coming from 5.x

No data migration is required. The platform namespaces have moved under https://w3id.org/atomgraph/linkeddatahub, so existing deployments need to re-seed. Stylesheets using the old Bootstrap 2 modes must be updated for the new design system. See Migrating from 5.x for the changes and the CHANGELOG for the full history.

Run it

Two public sites already run on 6.2.2: linkeddatahub.com and linkeddata.lt. To run it yourself:

git clone --branch linkeddatahub-6.2.2 https://github.com/AtomGraph/LinkedDataHub.git
cd LinkedDataHub
cp .env_sample .env
make up -- --build

On first run, make up generates secrets and the server certificate, builds the image and starts the stack at https://localhost:4443/. The getting started guide covers the remaining setup. To work with LinkedDataHub through Claude Code, install the plugin:

/plugin marketplace add AtomGraph/LinkedDataHub
/plugin install ldh@linkeddatahub

What comes next

For years I have argued that RDF can make software architecture generic and data-driven, not only improve data integration. LinkedDataHub is how I put that into practice. There is work ahead, on federated dataspaces and on agent workflows, but the foundation is now solid enough to build new kinds of applications on.

LinkedDataHub is open source under the Apache 2.0 license. The source is on GitHub.

Martynas Jusevičius, founder of AtomGraph