Control over patient data: a decentralized perspective

The history of computing
started out centralized.

• Large mainframes provided computational power
  for an entire organization.
  • People brought punched cards to a control room,
    where they were processed by a machine.
• When networking came along,
  terminals interfaced with mainframes.
  • The server possessed magnitudes more
    computational power than the client.

Even when the Internet became popular,
data and CPU remained decentralized.

• The Web provided a way to:
  • retrieve information faster
  • retrieve information we did not have before
• Desktop software remained dominant.
  • Data remained on-device.
  • Processing remained on-device.

The software-as-a-service model brought
storage and processing to the cloud.

• Centralized software platforms reduced friction.
  • Sharing becomes easier by linking.
  • Real-time collaborative editing becomes possible.
  • Users always have the latest software.
• Data processing and storage are outsourced.
  • Once again, our devices act as terminals.

A history of (de-)centralization
is driven by more than just technology.

• The technological gap between clients
  and servers is smaller than ever.
  • Servers resemble ordinary computers.
  • Even some of our portable devices are more powerful
    than our personal computers were a decade ago.
• Many cloud applications could still run on-device.
  • The UI in fact often does.
• Cloud business models have economic benefits.

Decentralization was an assumption
when the Web was designed.

• Internet
• email
• FTP
• …

The Web’s novelty was universality.

The Web strives to be universal
through independence of many factors.

• Anyone can use the Web, regardless of:

  hardware

  desktop

  phone

  tablet

  watch

  …

  software

  operating system

  browser

  app

  …

• Developers are free to innovate.
  • Build for the Web.
  • Standards provide interoperability.
• Unfortunately, this is not the default elsewhere.
  • App stores are a prominent counterexample.

In 2017, Tim Berners-Lee listed
three challenges for the Web.

1. We need to regain control
   over our personal data.
2. We need to reduce the spread
   of misinformation.
3. We need transparency and understanding
   of political advertising.

All three indicate a loss of control/agency.

Tim Berners-Lee is spearheading Solid
as an ecosystem to take back control.

• Solid is a way of building Web apps that
  let people keep control of their data.
• Solid combines existing W3C standards
  to define how agents should interact.
  • It is not a new Web:
    it builds on top of the existing Web.
• Like the Web, Solid is for everyone.
  • Bring back universality.

Solid aims to restore choice
by separating data from apps.

• Typical platforms nowadays store data
  inseparably from an application.
  • If we need to access the data, we cannot choose our app.
  • If we need to use the app, we can’t choose our data source.
• By separating data from apps,
  we create independent choices.
  • In essence, we‘re taking Web apps back to desktop mode,
    where one file can be opened by multiple apps.

For every piece of data an actor produces, they can choose where to store it.

They can grant apps and people access
to very specific parts of their data.

Separating app and storage competition
stimulates sustainable innovation.

Solid is not a platform to replace others,
but a way of building for the Web.

• Solid is an ecosystem.
  • Standards enable interoperability
• Solid is a movement.
  • We need to shift the app builder mindset.
• Solid is a community.
  • Building Solid requires different people,
    companies, and organisations.

A Solid server acts as a data pod
that stores and guards your data.

• It is a regular Web server
  • …with support for access control.
  • …with support for Linked Data.
• Its interface is application-agnostic.
  • Build any application, like on the Web.
  • Application-specific logic resides in clients.
• A Solid pod is essentially a website with data.
  • Its data is compatible with any Solid app.

A data pod can contain any data
you create or need online.

• profile 👤
• media 🖼
• comments 🗣
• likes 👍
• … ✨

Solid clients are browser or native apps
that read from or write to your data pod.

• People give read and/or write permissions
  for specific pieces of data to:
  • apps
  • other people
  • automated agents
  • …
• Apps deliver an integrated experience.
  • Instead of displaying individual webpages or data items,
    apps interleave data from multiple sources.

Any app you can envision,
you can build with Solid.

• calendar 📅
• social feed 👥
• photo sharing 📸
• conference organization system 🎤
• … ✨

Client–server communication is governed
by the Solid specifications.

• They essentially demand compliance
  with a couple of existing standards:
  • HyperText Transfer Protocol (HTTP)
  • Linked Data Platform (LDP)
  • Linked Data Notifications (LDN)
• They suggest specific RDF vocabularies.

Several open-source implementations
of servers, apps, and libraries exist.

• server
  • Use a public instance or host your own.
• apps
  • data browser
  • contacts
  • photos
  • meeting organizer
  • …
• libraries
  • authentication
  • data processing
  • …

Interoperability challenges in Solid
are solved through Linked Data in RDF.

• If we all store our own data,
  how do we connect it to others’ data?
• How can apps share data,
  without too many prior agreements?
• How do we integrate data
  from multiple data pods?

With JSON-LD, every piece of data
can link to any other piece of data.

{
  "@context":  "https://www.w3.org/ns/activitystreams",
  "id":        "#ruben-likes-ugent",
  "type":      "Like",
  "actor":     "https://ruben.verborgh.org/profile/#me",
  "object":    "https://www.ugent.be/#this",
  "published": "2019-04-25T08:00:00Z"
}

Data shapes and their semantics
enable layered compatibility.

{
  "@context":  "https://www.w3.org/ns/activitystreams",
  "id":        "#ruben-likes-ugent",
  "type":      "Like",
  "actor":     "https://ruben.verborgh.org/profile/#me",
  "object":    "https://www.ugent.be/#this",
  "published": "2019-04-25T08:00:00Z"
}

Different source data
can be concatenated.

{
  "@context":  "https://www.w3.org/ns/activitystreams",
  "@graph": [{
    "type":      "Like",
    "actor":     "https://ruben.verborgh.org/profile/#me",
    "object":    "https://www.ugent.be/#this",
    "published": "2019-04-25T08:00:00Z"
  },{
    "type":      "Like",
    "actor":     "https://example.org/people/silvia#me",
    "object":    "https://www.ugent.be/#this",
    "published": "2019-04-25T08:05:00Z"
  }]
}

The Paradox of Freedom:
you can only be free if you follow rules.

• Decentralization means making our own choices.
• Unless we agree on some basic things,
  no one will see the result of our choices.
• Agreement can be layered:
  • 100% agrees on a small set (labeling, authorship, …)
  • 80% agrees on a larger set (places, dimensions)
  • 5% agrees on many smaller sets (sizes, colors, …)

We need to identify those rules
we all need to agree on.

• vocabularies
• data shapes
• interfaces

Lessons learned from aggregating hundreds of datasets
are highly useful to inform the discussion.

Decentralization needs replication
for realistic performance.

In addition to technological changes,
we need a shift of mindset.

• from the one
  to one of many
• from source
  to station
• from platform
  to service

Current networks are centered
around the aggregator.

We need to create network flows
to and from the aggregator.

The individual network nodes
need to become the source of truth.

Aggregators need to become part
of a larger network.

Aggregators serve as a crucial
but transparent layer in the network.

Aggregators’ main responsibility becomes
fostering a network between nodes.