
## Our democracy and the Internet

Two of our favorite inventions.
Too bad they don't work so well together yet.
There are two problems we need to solve:

### 1. The internet can play a better role in our democracy

There are millions of us living in a country, but all the big decisions are made by small groups in old wooden rooms.
Countless valuable insights and ideas are skipped because of this.
With the Internet, people could share their ideas, think along and give their opinions from all sorts of places.

### 2. Social media are not designed for solving problems

Social media are mostly designed for people to look at ads, not to solve problems together, or to get a nuanced view of something.
Online discussions are often cluttered, terse, and thus not very useful.
Understandably, then, many organizations are afraid to use the Internet.

<BigImage image="cases/argu_abstract_en.png" />

## Our solution

So we set to work to build an online democracy platform.
Designed to make it as easy as possible for citizens to participate, and for civil servants to ask questions in the best possible way.
We launched Argu in 2015, and have now completed over 150 participation projects.
We have built in numerous [functionalities](https://argu.co/info/functionaliteiten), such as digital voting, responding, dynamic forms, questionnaires, map views, notifications, rights management, groups, custom domain names, export capabilities, custom theming, and much more.

<BigImage image="cases/argu_body.png" />

## Technology

Argu is by far our biggest project, and a major source of our revenue.
It is a SAAS solution that we have been developing and keeping live for several clients for years.
Developing Argu has taught us to create web applications that are maintainable, flexible and scalable.

Argu's stack consists of several services, two of which are particularly relevant:

### Back-end: Apex

The foundation of our back-end of Argu is built based on [Ruby on Rails](/en/tech/ruby-on-rails).
Given that we had the desire to make the data available as [Linked Data](/enl/blog/what-is-linked-data), we wrote an Open Source library for this: [Linked_Rails](https://github.com/ontola/linked_rails).
This gives Apex a number of unique qualities:

- **Everything is linked data**. Even the buttons, forms, and actions are described as data. This gives us great flexibility, so we can use the same source code for very different use cases.
- **The API is the same as the website**. If you can view a page, you can retrieve the data from that page using the same URL. Actually incredibly logical (see our [article on API design](/blog/api-design)), but oddly enough quite rare.

### Front-end: Libro

Libro is a web application written in [React](/en/tech/react) + [Typescript](/en/tech/typescript).
Libro stands for _linked data browser_.
This is what makes Libro unique: at its core it is not a regular app, but a _data browser_.
Under the hood, libro works with the [Link libraries](https://github.com/rescribet/link-redux), developed by our CTO Thom van Kalkeren.
Libro communicates exclusively with Apex by exchanging linked data (RDF).
We are one of the first SAAS companies to put linked data so far into its stack.
That has given us [some unique challenges](/blog/full-stack-linked-data/), such as a performance bottleneck for which we developed a [new RDF serialization format](https://github.com/ontola/hextuples).

## Created with

<TechWrapperSmall>
  <TechPill technology={'react'} />
  <TechPill technology={'ruby-on-rails'} />
  <TechPill technology={'typescript'} />
</TechWrapperSmall>


An online democracy platform, to help organizations reach their constituencies.

Argu


## Decentralizing the Internet Again

In 1989, Tim Berners-Lee published the first website.
In doing so, he had a vision of a decentralized internet, a web, where people would host their own websites on their own servers.
Now we're more than 30 years on, and the web is more centralized than ever.
A handful of tech giants manage our data, determine what our digital interactions look like, and in what order we read our news.
We need to be able to do that differently.

Tech giants are keeping us on board by connecting our own data.
For example, your Google Calendar works perfectly with your GMail, and you can quickly attach your Google Drive files.
As a tech giant, you have the data to link all of this together, making users dependent on your services.
Fortunately, there is another way to solve this: **standardize**.
With good standards, we can move our data from App to App, so you don't get stuck in the ecosystems of the tech giants.
In addition, by standardizing a lot more, you can do things you can't do now, like search through all your data, see who changed what and when, open the same data in different apps, and more...
But how do we get there?
What do standards need to meet before we can live in this tech utopia?

## From Linked Data to Atomic Data

Tim Berners-Lee gained an important insight 10 years after the first website: the same links we use for websites, we can also use in _data_.
Thus _Linked Data_ was born.
Linked Data makes it possible to use the entire web as a large, connected database.
With that, you could create apps that are completely decentralized, that work much better together, where people themselves have full control over their data.

At least, that's the theory.
In practice, it is still very difficult to build apps with Linked Data.
We can know, because as Ontola we went [all-in](/blog/full-stack-linked-data) on this technology a few years ago.
We rewrote our e-democracy platform [Argu](https://argu.co) and used Linked Data for literally every button and menu.
This was a big job, and we had to create numerous tools to achieve this goal.
From this year-long development process, we learned how to make Linked Data even better - and most importantly, much _easier_.

Our CEO Joep Meindertsma started working on a new form of Linked Data in 2020 in his spare time.
The goal: to find an easier, more powerful abstraction that would allow developers to more quickly create apps that work well together.
Grabbing the best stuff from Linked Data, but improving where possible.
After a few months, there was a [comprehensive documentation](https://docs.atomicdata.dev/) of Atomic Data online, and not much later the first server, libraries and browser.
As a result, Atomic Data quickly became a pretty mature system, with solid implementations and various tools.

## Why Atomic Data

- **Faster Standardization**. Tuning how to shape a particular model is too often a time-consuming task. As a result, there is _too little standardization_, and that limits how well applications can work together. Atomic Data is designed to share data models quickly and easily.
- **Faster development**. Existing tools (such as Atomic-Server) allow you to get started quickly, and you don't have to reinvent the wheel. Storage, searching, versioning, rights management.... It's all already taken care of.
- **Convertible to virtually anything**. You can export Atomic Data to virtually any format: JSON, XML, JSON-LD, RDF, Turtle, N-Triples...
- **Easy to share**. All objects have links, and these links can be looked up - just like websites. The data itself describes where you can find more information. This makes Atomic Data very sharable.
- **Verifiable and correctable**. Atomic Data introduces [Commits](https://docs.atomicdata.dev/commits/intro.html), which stores every change. This creates a history of each object, so you can always determine who did what and when.
- **Authentication and authorization**. Control who has access to which piece of data.

## The best of linked data, JSON and type safety

- **The simplicity of JSON**. Developers know it, and it works everywhere.
- **Type safety**. You can be sure your data has a certain type.
- **Linked data**. Link your data together - even if it's on different machines.

<img src="/images/cases/atomic_venn.svg" />

## What we've built

- [**Atomic-Server**](https://crates.io/crates/atomic-server): a very fast database + server, written in Rust.
- [**Atomic-Data-Browser**](https://github.com/joepio/atomic-data-browser): front-end application for management and display of Atomic Data.
- [**Atomic-CLI**](https://crates.io/crates/atomic-cli): convenient command-line interface tool
- [**Atomic-lib**](https://crates.io/crates/atomic_lib): library for Rust
- [**@tomic/react**](https://www.npmjs.com/package/@tomic/react): library for React, see [template on codesandbox](https://codesandbox.io/s/atomic-data-react-template-4y9qu?file=/src/MyResource.tsx)
- [**@tomic/lib**](https://www.npmjs.com/package/@tomic/lib): library for javascript / typescript
- [**Documentation**](https://docs.atomicdata.dev/): over 80 pages of technical specifications and examples.

## Atomic Server

Atomic Data is a modular specification, which means you can grab bits from it that you find useful, but you don't have to use everything.
If you want to get started quickly, we recommend using our Atomic-Server, which has all the specs implemented.

Atomic-Server is a powerful, extremely fast database + server with an incredible amount of features.
Completely free and open source.
Written in the Rust programming language.
The front-end is written in [Typescript](/en/tech/typescript) with [React](/en/tech/react).

Atomic-Server is designed to be the personal server of the future: a lightweight application that you can easily run at home on a cheap computer, like a Raspberri Pi or an old smartphone.

[Read how to install Atomic-Server here](https://github.com/joepio/atomic-data-rust/).

<video controls src="https://user-images.githubusercontent.com/2183313/139728539-d69b899f-6f9b-44cb-a1b7-bbab68beac0c.mp4"/>

## Created with

<TechWrapperSmall>
  <TechPill technology={'react'} />
  <TechPill technology={'rust'} />
  <TechPill technology={'typescript'} />
</TechWrapperSmall>


An ambitious, fully open source initiative to increase data ownership and make apps work better together.

Atomic Data


## The question

As a political party, your members are your most important tool for growth - they are your campaginers.
An important part of their activities, is going door-to-door.
They need a route, where are they going to ring the bell?
Which areas require most attention, which have the most potential?
And above all - what do they do with the results?
GLAPP was developed for this purpose.

## Our solution

We developed the GLAPP, the Green Left App.
This web application makes it easy for volunteers to join the campaign and for campaign managers to make sure everything goes smooth.

## Processing results

Results of the conversations volunteers have while going door-to-door are entered into the GLAPP.
This updates the potential in that neighborhood, so other volunteers know in which areas they have most impact.
The data is always converted to an average on street level, so no personal data is stored.

## Privacy first

For our client, privacy is a major concern.
That's why we kept privacy in our mind during every step of the development.
Filtering our logs, limiting access to data from certain areas, two factor authentication, aggregating results instead of storing it per address: everything to make sure no personal data is ever stored or shown to and unauthorized user.

## Multilevel dashboards

We created multiple dashboard so different people with different roles can access the data they need.
The data can be filtered and exported to fit all uses.

## Gamification

Doing repetitive tasks can be exhausting.
That's why we made the app not only as easy to use as possible, but also fun to use! Both campaign managers and volunteers are encouraged to continue their efforts by showing cheerful texts and granting badges for their hard work.

<BigImage image="cases/glapp_body.png" />

## Gemaakt met

<TechWrapperSmall>
  <TechPill technology={'react'} />
  <TechPill technology={'ruby-on-rails'} />
  <TechPill technology={'typescript'} />
</TechWrapperSmall>


A web application for Groenlinks, modernizing its online and offline campaigns.

Cases

Argu

Atomic Data

The GLAPP