There is no root, authority, or centralisation here. Control yourself!
dokieli is a decentralised article authoring, annotation, and social notification tool which works from Web browsers. It is built with the following principles in mind: freedom of expression, decentralisation, interoperability, and accessibility.
It can be used as a:
- single-page application - open any dokieli embedded article
- browser extension - import this repository in your Web browser or install Web Extension from Chrome Web Store or Add-ons for Firefox
- For brave developers and authors: the canonical documentation explains dokieli's principles, architectural and design patterns.
- For academics: Decentralised Authoring, Annotations and Notifications for a Read-Write-Web with dokieli
- Information is represented and retrieved following the Linked Data design principles.
- WebID for personal/agent identities.
- WebID-TLS and WebID-OIDC for authentication.
- Web Access Control/ACL to set permissions on Web resources.
- W3C Linked Data Platform and Solid-like servers to read and write Web resources.
- W3C Linked Data Notifications for inbox notifications for annotations and social sharing.
- W3C ActivityPub client to read/write from/to profile's outbox.
- W3C Web Annotation Model, W3C Web Annotation Vocabulary, W3C Embedding Web Annotations in HTML, and W3C Selectors and States to model and identify annotations (eg. replies, peer-reviews, liking, resharing, bookmarking)
- W3C Activity Streams 2.0 vocabulary for social activities.
- W3C ODRL Information Model and W3C ODRL Vocabulary & Expression to represent statements about the usage of content and services.
- Memento for resource management eg. TimeMap.
- Creative Commons to assign license to individual contributions and annotations.
- Robust Links for hyperlinks eg. citations, and to show Link Decoration.
- schema.org, SPAR Ontologies, PROV-O, and various other vocabularies.
- In-browser document authoring and formatting, and semantic enrichments (RDFa annotations).
- Content negotiation is possible for RDFa, Turtle, JSON-LD, RDF/XML.
- Uses author's information from their online profile (WebID).
- Creation of new documents from any existing dokieli document - part of self-replication.
- Save document and its dependencies to a new location (anywhere on the Web given access) - part of self-replication.
- Open and edit (HTML+RDFa) URLs.
- Individually assign the language of articles and annotations and parts within.
- Assignment of URI fragments (to any unit of significance) so that other resources on the Web can link to it.
- Implements versioning and has the notion of immutable resources.
- Embedding data blocks, e.g., Turtle, N-Triples, JSON-LD, TriG (Nanopublications).
- Embedding of media objects, tables, and interactions.
- Automated references and citations (retrieves and reuses structured information).
- Insertion of table of contents, figures, tables, abbreviations.
- Drag and drop to reorganize the document's sections and table of contents.
- In-browser local storage, and document exporting.
- Document metadata.
- Views for screen and print (e.g., ACM, LNCS) - yes, you can output to a paper user interface: PDF
- .. and many more on the way.
"Yea, okay, whatever, it doesn't do x, y, z!" You are welcome to create issues, discuss, or pull requests. Make it so!
Also available on https://dokie.li/ (with captions):
- Overview: https://dokie.li/media/video/dokieli.webm (a little old, see shorter/newer Annotation below)
- Annotation: https://dokie.li/media/video/dokieli-annotation.webm
- Share: https://dokie.li/media/video/dokieli-share.webm
- Citation: https://dokie.li/media/video/dokieli-citation.webm
- Sparqlines: https://dokie.li/media/video/dokieli.webm (see also article)
See the growing list of examples in the wild. Add the URLs of your articles or interactions to the list.
This repository is published and accessible from https://dokie.li/. dokie.li is intended to demo and exemplify what we can do with this technology. You are welcome to use and experiment with dokieli there, or anywhere else you come across a dokieli document.
For the scholars among us, see the authoring guidelines below. View the ACM guidelines using the LNCS typographical rules, and vice versa (see the menu) ;)
- Read: client either loads local HTML files or fetches remote URLs, in that case the host sends HTML etc. All content is accessible at minimum from a text-browser
- Local write: Web browser with JavaScript enabled (use export or local storage)
- Remote write and access control: above plus WebID and personal online storage
These libraries are part of the dokieli distribution:
- SimpleRDF (MIT License) used for RDF.
- Font Awesome (CC BY 4.0 License / MIT License) for icons.
- MediumEditor (MIT License) for document editing.
- d3 (BSD 3-Clause) used for visualisations.
- Shower (MIT License) used for slideshows.
- Use it. Break it. Report it. Fix it! See issues.
- Improve documentation (for the website or repository)
- Publish articles with it.
- Join the dokieli chat for help and discussion.
- Encourage the ideas/movement and however else you want to contribute.
- General background in dokieli documentation.
- See fork a repo to setup
your own development repository and stay
synchronised. Useful later
to make pull requests. For example, using your fork at
https://github.com /YOUR-USERNAME/dokieli:
# Clone your work repository, for example:
git clone [email protected]:YOUR-USERNAME/dokieli
cd dokieli
# Add the main repository to sync with
git remote add upstream https://github.com/linkeddata/dokieli
# Make sure to work off your main and synchronised
git checkout main
git fetch upstream
git merge upstream/main
# Install packages
npm install
# Check out a branch for your changes
git checkout -b YOUR-WORK-BRANCHNAME
# Make your code updates at src/ , media/ etc.
# Build eg. to create scripts/dokieli.js
npm run build
# or automatically rebuild when files change
npm run watch
# or create a minified scripts/dokieli.js
npm run minify
# Test your changes, if all okay:
# Note: The add/commit lines below can be combined with `commit -am`
# If including scripts/dokieli.js, make sure that it is the minified version
# Add the changes you've made to staging
git add PATH/TO/FILE
# Commit staged changes with a useful message
git commit -m "Add x to do y"
# Push changes to your work repository
git push
Pull requests should be a single commit. It keeps the commit log concise and helps a lot towards the review process. There should not be any commits about merges or reverts in the commit history. See GitHub's pull requests for the remaining steps on how to propose your changes to be brought into dokieli's repository.
- Crosscloud (2015-10 — 2016-09)
- MIT CSAIL (2015-10 — 2016-09)
- Amy Guy
- Amy van der Hiel
- Andrei Vlad Sambra
- Ben Companjen
- Benjamin Young
- Chris Chapman
- Dmitri Zagidulin
- Gerben Treora
- Henry Story
- Herbert Van de Sompel
- Kingsley Idehen
- Melvin Carvalho
- Nicola Greco
- Pascal Christoph
- Renato Stauffer
- Ruben Taelman
- Ruben Verborgh
- Sandro Hawke
- Sarven Capadisli (maintainer)
- Sergey Malinin
- Thomas Bergwinkl
- Tim Berners-Lee