Open rescribet opened 4 years ago
This leaves two main interfaces / API surfaces to be defined;
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:
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;
Other possible package distribution methods; (app) store, vendor injection, sysadmin/group-policy.
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.
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.
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.
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.
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.
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.
*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