Notice to Affiliate Researchers

I have described my SoP artifact as a super-janky Roam/Notion clone on top of a fully-exportable RDF graph with other protocol-ish characteristics. Unlike those products, this is a completely self-hosted, white-label, standards-compliant system, ultimately intended for developing more purpose-specific systems. The goal is to raise the floor for creating knowledge graphs and other dense hypermedia environments. I endeavour to get an end-to-end prototype working in time for the retreat. Development on said prototype is a one-person job, but if you're interested in exploring possibilities for making things on top of it, kindly reach out.

I am in the Eastern time zone which for the duration of the summer is UTC-4. In general I am at my desk Mondays through Fridays, from 8am to 11am and then again from 2pm to about 10pm, unless I am not. I will not be setting up a Calendly; just contact me through the SoP Discord.

Restated Technical Objectives

This summer's protocol artifact target is to overhaul the Intertwingler package, currently a static website generator, and turn it into a live engine for authoring and interacting with dense hypermedia. This is a speaking artifact; its goal is to demonstrate a configuration that will retrofit the Web with certain capabilities it lacks by default, which in turn will span a gap that I currently characterize as too complex for a spreadsheet, economics too out of whack to become a product. This is something I envision individuals—initially techncially-inclined ones—using to create their own apps and information systems, but even also art and literature.

Here is a set of subsidiary technical goals needed to achieve the main one:

Eliminate link rot

We can't really do anything else without first solving the problem of link rot, which is a high-value target on its own. If we're going to jack up the amount of addressable resources—and thus links (and by this I mean embeds too)—by several orders of magnitude, we need those addresses to be durable.

Eliminate much of the gruntwork of Web content management

I say dense hypermedia to contrast what I judge the Web's off-the-shelf bias to be, which is sparse hypermedia:

• Big, opaque documents,
• very low internal addressability,
• data semantics are poor to nonexistent,
• almost no links besides main and secondary navigation.

In other words, the median website is scarcely more than a big collection of Word documents. I submit this is a problem of paradigm. We want to get as far away as we can from the trivia of building a website so we can focus on creating knowledge graphs and other dense hypermedia environments. For one, there are a number of resources which can be construed as derivatives of other resources, and there are a number of ways the same information resource can have more than one representation:

• Cropped and resized (and otherwise straightforwardly manipulated) images,
• derivative media types (e.g. Markdown to HTML to PDF, but also mundanities like JPEG to WebP),
• injection of metadata,
• alternate representations (e.g. a chart from a data table, or JSON of the same),
• composite documents (i.e. most Web pages reuse, at minimum, headers, navigation, and footers).

That is, a resource derived from R can be expressed as F(R), or rather a URL-appropriate analogue. This means a couple things: for one, we don't have to dream up URLs for these things; we can derive them. What this also means is that the transformations become clear and discrete development targets. It also means that updates to a master resource will propagate automatically to all its derivatives, meaning there are no rogue old versions of things hiding around, and you only need to manage one conceptual entity instead of several.

Establish extremely well-defined development targets

The idea here is to design this system so it is embarrassingly simple to extend. This is very much like the Linux kernel's relationship to modules: Torvalds defines an interface and contributors conform to it. In our case, everything that either generates content or operates over it is descended from a single species of microservice. These microservices can be developed and tested in isolation, and loaded into a main bus. The microservices aren't completely arbitrary; they will have to follow a minimal protocol (forthcoming) in order to be compatible, but this strict definition will greatly narrow down the decision space of what a developer needs to code.

Dramatically reduce the overhead of prototyping knowledge graphs

One critical objective of this project is to aggressively shrink the cost of designing knowledge graphs and other dense hypermedia. The ultimate layout of the user interface is contingent on having a corpus which is large and diverse enough to represent the kind of content that the graph is intended to contain. Much of this can be anticipated in advance, but in my experience, real data will always surprise you. This means supplying a generic user interface to get the data into the graph, which can then be supplanted by specific user interface elements once there is enough content. The user interface programming layer will therefore need to be highly responsive to adapt not only to these surprises, but also new types of entities and relationships introduced later on.