In the beginning, there was a scientist working on her data on her computer with the help of an app on her computer.

Then she made a web app, and other scientists could see her data, but only what she made available and the way she made it available.

So, she made a data app that published her data. And, she became a client for her data app and made a web app.

Now, others could not only see her data through her web app, they could also see her data app. They liked this idea, and did the same.

Others liked the idea and joined the party. Some made only web apps, others made only data apps, while yet others made both, and even more only used them.

They continued to work the way they always did, without changing their tools and technology. No one placed any demands on another, no one’s burden was increased.

The only tacit agreement was that they all agreed to adhere to very minimum and easy standards for building data apps because they recognized the benefit of doing so.

So, how does this all work? A desire to make one’s data accessible by others, and a common understanding to follow a few very lightweight standards.

Every one is free to continue to use what they are already using. No one has to change their mode of work or their favorite technology.

We depend on Representational State Transfer (REST) as the architectural style and JavaScript Object Notation (JSON) as data transport format.

No one is obligated to provide their data to anyone, and no one is beholden to anyone. The only concession is to adhere to a common interface.

When a user finds some one else’s data useful, the two form a relationship.

If the other user finds use for the first user’s data, well, that is even better as the relationship is symbiotic.

Given a large number of users participating in this way of opening up their data, everyone will benefit from someone’s work.

But, it will be even better if the data publisher could keep count of how many users took the data.

Since access to the data, be it via the web or through the command line, is exclusively via a web server, the publisher always knows the use count.

With no middleman, it is easy to track when B uses A’s data as B leaves information in A’s logs.

But, what would happen if C takes A’s data from B? That is a difficult problem worth solving. No answer yet, but more on that soon.

A complementary issue is for the user to know what can be done with the data.

What can be done with the data is usually driven by what the data publisher permits.

Most scientific data may already be in the public domain. Yet, it is a good practice to publish the data with a data license accompanying all data packets.

Make your data available.

Make your data available.

Always serve your data via a web server.

Make your data available.

Always serve your data via a web server.

Always create a data app first.

Make your data available.

Always serve your data via a web server.

Always create a data app first.

Build other apps on top of the data apps.

Your data is a resource.

Your data is a resource.

Make your resource identifiable by a unique name.

Your data is a resource.

Make your resource identifiable by a unique name.

This is the Uniform Resource Identifier (URI).

Cool URIs don’t change. This is your contract to your community.

Because each scientist speaks a different language, we need a common interface to connect everyone.

Our common interface is the hypertext transfer protocol (http) and its limited set of verbs such as GET, PUT, DELETE, POST.

Our data transfer format of choice is JavaScript Object Notation (JSON), where possible.

You and others can do more with raw data than with cooked data.

You and others can do more with raw data than with cooked data.

Think data apps that publish raw data. (raw up to the level it makes sense)

You and others can do more with raw data than with cooked data.

Think data apps that publish raw data. (raw up to the level it makes sense)

Each datum is a resource.

You and others can do more with raw data than with cooked data.

Think data apps that publish raw data. (raw up to the level it makes sense)

Each datum is a resource.

Each resource has a unique name.

You and others can do more with raw data than with cooked data.

Think data apps that publish raw data. (raw up to the level it makes sense)

Each datum is a resource.

Each resource has a unique name.

And, is accessible by a canonical URI.

You and others can do more with raw data than with cooked data.

Think data apps that publish raw data. (raw up to the level it makes sense)

Each datum is a resource.

Each resource has a unique name.

And, is accessible by a canonical URI.

Choose JSON (or other format) for data transfer.

You and others can do more with raw data than with cooked data.

Think data apps that publish raw data. (raw up to the level it makes sense)

Each datum is a resource.

Each resource has a unique name.

And, is accessible by a canonical URI.

Choose JSON (or other format) for data transfer.

Provide a few standard resources for discovery

• author
• version
• license
• resources