RFC: Modular architecture

[rescribet]

In a nutshell

This proposal makes for an application deployment platform like the current web, but based on the linked data principles

Changing the current implementation

The current system includes some views by default (e.g. address bar, extension manager, file manager), though these aren't really necessary to pre-include.

Drawing inspiration from how Unix systems work, the core only provides the base to get up and running from the developer console ('f12' console), then packages can be added on top which will give the application additional functionality. Users will be able to completely change all browser chrome and companies can create distros which have views and functionality tailored to their data pre-compiled.

Layer	Subcomponent
RDF Resource / RDF website
	preferences
	package list
RDF packages
	views
	topologies
	middleware
	Data / ontology
RDF browser kernel
	package manager (APIs)
	core middleware
	link-redux?
	link-lib
Web browser* / OS

*The web browser is used as a backwards-compatible infrastructure to deliver the RDF browser application. Technically any platform which can run the RDF browser will suffice

[rescribet]

This leaves two main interfaces / API surfaces to be defined;

Kernel API

• Package manager API's for the user to add/remove packages from the system
• Core middleware to provide a common set of low-level/os restricted actions
• Other system API's to provide component registration, view selection, data/network interfaces, reasoning capabilities, etc. (primarily for low-level view frameworks, e.g. link-redux)

Package interface

Two surfaces have to be defined;
RDF: Via an ontology which can be used to describe what a package contains (funtional) and how it can be consumed (technical).
JavaSript: Defines how packages should present/register themselves when loaded.

To consider:

• Authorship
• Signing
• Versioning
• Dependencies

RDF Resource / RDF website

Most data doesn't follow a strict structure which maps directly onto a view sensible for human consumption (which is what HTML+CSS currently provide). Like the web, the data is distributed and its structure cannot be known in advance, especially with the open world assumption. Rendering information is therefore distributed across the data architect, the producer, the publisher, and the consumer. To accommodate this distribution, I'm proposing to store information about which packages to install at those separate places;

• The data architect in the ontology
• The data producer which can give hints on data instances
• The publisher at a .well-known location
• The end-user's storage (localstorage, pod)

Other possible package distribution methods; (app) store, vendor injection, sysadmin/group-policy.

[rescribet]

Common development surface

It can be expected to be valuable to have a consistent interface while loading packages from vastly different sources. Since the kernel will not provide any default views or middlewares, an important aspect for distributed development is a common foundational library.

Some toolkit akin to gnome, QT, WPF, etc, to have a common development surface as per what type of components, topologies, and actions can be reliably expected to exist in a browser while not bloating the app with different versions/distributions of the same concept.

When all actions are IRI's, different systems can consume the same actions, allowing for evolution of underlying technology while keeping the API consistent.

[rescribet]

Examples

Scientific publication

Architect

Who
CERN

What
The LHC generates a lot of data which is analysed by scientists around the globe. To increase cooperation and searchability across the publications from the teams of scientists, they have defined an ontology which the teams can use to describe their research on the LHC data.

View lookup
The CERN has also made views to look at those reports. They embedded links to their view packages for each class/property in the ontology they published.

Producer

Who
Team of scientists at a university

What
The team interprets data from the CERN and publish their findings using the ontology provided by the CERN. Their research described how they got additional insight into certain interactions by combining the interaction with additional data from a different set. They have built special views which contain logic for combining the datasets.

Why at this level
The scientists could define a small class for their combined data resources, but that would require them to have modelling knowledge, and distributors to ensure this information is present in partial distributions of the work as well.

View lookup
The scientists embedded links to their view packages on the data instances.

Publisher

Who
Elsevier

What
When publishing the article, Elsevier has added additional statements to the original publication (e.g. peer-reviews, licences, URI's, citations). As a publishing house they also want to provide convenience features their users in a recognizable way.

Why at this level
They re-use ontologies for adding this data so they cannot publish view recommendations there.
Their domain contains millions of data instances, so duplicating adding these would create considerable storage and maintenance overhead.

View lookup
The publication house has a list of their supported packages (some premium) under a /.well-known/ location on their domain.

Consumer

Who
Journalist

What
A journalist is working with a multitude of publications, comparing and annotating them.

Why at this level
The journalist has created these views for a specific article they have been working on, later sharing might be useful, but the project has to remain secret until the publication has been done.

View lookup
The settings from their pod storage, where the JS files also live.