Dokieli: Decentralised Authoring, Annotations and Social Notifications

“Hypothesis and Genius make it possible for users to leave annotations on different types of documents on the Web using a browser plugin or via a proxy. Annotations may be private or public, and can be threaded to form conversations around a piece of content. Despite allowing the attachment of annotations to resources hosted anywhere, they depend on centralised account creation and storage for the annotations themselves. Hypothesis is open source, with an API that uses the data model currently undergoing standardisation in the W3C Annotations Working Group, and may be self-hosted, but currently it is not possible to federate between different Hypothesis instances. There have been many tools for semantic authoring of textual content [5]; here, we note four. Loomp [6] and RDFaCE [7] are semantic content authoring tools which respectively follow a top-down and bottom-up approach with HTML+RDFa. Loomp allows annotating terms with concepts from Linked Data ontologies, and creating relationships between annotated phrases. Loomp can be self-hosted, and uses a server-side triplestore. RDFaCE is a Web-based RDFa content editor based on the TinyMCE rich text editor. It supports different views for semantic content authoring and uses existing Semantic Web APIs to facilitate annotating and editing of RDFa content. RDFaCE uses on-the-fly client-side triple storage.” ⤴️
“The tools which provide good collaborative editing UIs appear to do so at the expense of data ownership and interoperability; those which promote creation and publication of data in open reusable formats are lacking facilities for linking discourse and conversation to concepts published. What follows is a proposed architecture for bridging this gap which has a low setup cost.” ⤴️
“The native serialisation for dokieli documents is HTML+RDFa” ⤴️
“RDFa allows authors to add semantic structure to their ideas inline. Alternative syntaxes such as Turtle, JSON-LD, and TriG may be embedded into HTML as raw data islands, though this causes unnecessary separation, and potential duplication and desynchronisation of data. dokieli uses these to compliment the prose but does not rely on them.” ⤴️
“any individual word, phrase, paragraph, or other subsection of a document can have its own unique identifier using a fragment URI. This enables responses to be targeted very specifically at parts of a document; when additional semantics are applied to relationships, we have the power to create links that say things like ‘I like this concept’, ‘this sentence should be clarified’, ‘this result disagrees with those conclusions’.” ⤴️
“dokieli does not mandate the use of any particular RDF vocabularies as the content of an article dictates how it is best described.” ⤴️
“dokieli application logic, written in JavaScript, is distributed along with every document, ensuring all documents can be edited and interacted with. We consider this a default UI of a document” ⤴️
“The progressive nature of dokieli documents is fault-tolerant. If the application scripts or stylesheets are not available, the content is still accessible, allowing continuous utility, albeit in a read-only mode, rather than failing completely. A single document in HTML+RDFa is able to retain all of its core content and semantics without external dependencies.” ⤴️
“dokieli is self-replicating, in that the reader of a dokieli document can spawn an instance” ⤴️
“documents can be served from the local filesystem for individual use. To publish documents more widely, they can be hosted on an ordinary Web server, and disseminated with a URL.” ⤴️
“The core capabilities of dokieli are enabled on a per-document basis,” ⤴️
“Articles may be stored on user’s local filesystem or hosted from ordinary Web servers which can serve static HTML files, for example: university user pages, code repositories, personal or company webspace, or any file hosting” ⤴️
“Articles can be edited in a Web browser, and then exported (figure 15) to save changes.” ⤴️
“A document stored on a Solid server is readable as a normal HTML page, and additionally editable directly on the server for authorised users (figure 15).” ⤴️
“The user has the option to copy media and scripts to their own space as well, link to them from a CDN or link to them from the document they are starting from.” ⤴️
“Rather than centralising these interactions around the subject document, we took the decision to default to decentralisation of all content by allowing users to authenticate with their personal dataspace, and choose the location for their interactions at the point of making them.” ⤴️
“This gives rise to the need for a mechanism to notify the original author that their document has received some interaction. We do this by allowing document authors to specify an inbox for either their article as a whole, or any subsection with its own URI using the ldp:inbox predicate. Inboxes are containers in a dataspace which may be appended to by anyone, and do not need to be on the same server as the document itself; if one article has multiple inboxes they can be distributed across as many dataspaces as is convenient for the author(s). When an annotation is made, dokieli follows the appropriate inbox link and writes a notification there (see figure 17 for this process and listing 1 for notification contents). When the document is loaded, links are followed to all inboxes in order to retrieve interactions there have been notifications about, so that these can be displayed along with the document (figure 18 and figure 19).” ⤴️
“Although providing enriched (meta)data is voluntary, provenance level data like the date on which the request was submitted, who by, and its license, can be purposed towards the verification process as well as for displaying” ⤴️
“An author can also opt to allow anonymous interactions with their documents by pointing to a publicly writeable storage location in their own space, and store interactions on behalf of their audience.” ⤴️