<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:base="https://ruben.verborgh.org/">
  <id>https://ruben.verborgh.org/</id>
  <title>Ruben Verborgh's blog</title>
  <updated>2025-08-12T06:00:00Z</updated>
  <link rel="alternate" href="https://ruben.verborgh.org/" type="text/html"/>
  <link rel="self" href="https://ruben.verborgh.org/blog/latest.xml" type="application/atom+xml"/>
  <author>
    <name>Ruben Verborgh</name>
    <uri>https://ruben.verborgh.org/blog/</uri>
  </author>
  <entry>
    <id>tag:ruben.verborgh.org,2025-08-12:/blog/2025/08/12/inside-the-insight-economy/</id>
    <title type="html">Inside the Insight Economy</title>
    <published>2025-08-12T06:00:00Z</published>
    <updated>2025-08-12T06:00:00Z</updated>
    <link rel="alternate" href="https://ruben.verborgh.org/blog/2025/08/12/inside-the-insight-economy/" type="text/html"/>
    <content type="html">&lt;p&gt;Never mind the data economy.
Data is unfit to form a proper marketplace:
copyable goods cause an infinite supply
that leaves a deeply confused demand.
&lt;!-- Need:         Why something needed to be done at all   --&gt;
Meaningful trade only happens
when two sides believe and expect
they both stand to gain from every exchange.
With data,
it feels like some are always &lt;em&gt;giving&lt;/em&gt;
and others always &lt;em&gt;taking&lt;/em&gt;.
Is that because a broken marketplace
makes trade fundamentally impossible?
Yes.
&lt;!-- Object:       What the present document does or covers --&gt;
But this post is not a plea for giving up;
it’s a focused manifesto for doing better.
&lt;!-- Task:         What was undertaken to address the need  --&gt;
What marketplace can we build
where data benefits everyone through trade?
&lt;!-- Findings:     What the work done yielded or revealed   --&gt;
The question carries the answer:
don’t exchange raw data.
Refine each data point
into a tailor-made asset
that loses purpose when copied,
yet delivers value when traded.
&lt;!-- Conclusion:   What the findings mean for the audience  --&gt;
Change starts from the essential belief
that healthy data flows can bring more opportunities
for improvement than harm.
&lt;!-- Perspectives: What the future holds, beyond this work  --&gt;&lt;/p&gt;&lt;p&gt;&lt;a href='https://ruben.verborgh.org/blog/2025/08/12/inside-the-insight-economy/'&gt;Read more&amp;hellip;&lt;/a&gt;&lt;/p&gt;</content>
    <summary type="html">&lt;p&gt;Never mind the data economy.
Data is unfit to form a proper marketplace:
copyable goods cause an infinite supply
that leaves a deeply confused demand.
&lt;!-- Need:         Why something needed to be done at all   --&gt;
Meaningful trade only happens
when two sides believe and expect
they both stand to gain from every exchange.
With data,
it feels like some are always &lt;em&gt;giving&lt;/em&gt;
and others always &lt;em&gt;taking&lt;/em&gt;.
Is that because a broken marketplace
makes trade fundamentally impossible?
Yes.
&lt;!-- Object:       What the present document does or covers --&gt;
But this post is not a plea for giving up;
it’s a focused manifesto for doing better.
&lt;!-- Task:         What was undertaken to address the need  --&gt;
What marketplace can we build
where data benefits everyone through trade?
&lt;!-- Findings:     What the work done yielded or revealed   --&gt;
The question carries the answer:
don’t exchange raw data.
Refine each data point
into a tailor-made asset
that loses purpose when copied,
yet delivers value when traded.
&lt;!-- Conclusion:   What the findings mean for the audience  --&gt;
Change starts from the essential belief
that healthy data flows can bring more opportunities
for improvement than harm.
&lt;!-- Perspectives: What the future holds, beyond this work  --&gt;&lt;/p&gt;</summary>
  </entry>
  <entry>
    <id>tag:ruben.verborgh.org,2024-10-15:/blog/2024/10/15/trust-takes-time/</id>
    <title type="html">Trust takes time</title>
    <published>2024-10-15T06:00:00Z</published>
    <updated>2024-10-15T06:00:00Z</updated>
    <link rel="alternate" href="https://ruben.verborgh.org/blog/2024/10/15/trust-takes-time/" type="text/html"/>
    <content type="html">&lt;p&gt;Today’s websites and apps are built
to compensate for an absence of trust,
rather than to support its growth.
Customers and companies both understand that
human handshakes no longer scale in the digital age,
and surrender to their replacement
by a tap of the finger
on a button labeled &lt;q class="nobr"&gt;I accept&lt;/q&gt;.
While every handshake comes with an expectation of honesty,
this button never did:
we &lt;em&gt;know&lt;/em&gt; we are lying the moment we touch it,
as does the author of the legalese
no one expects anyone to read.
&lt;!-- Need:         Why something needed to be done at all   --&gt;
Navigating a trustless world
is a heavy price to pay
for the boundless freedoms of the World Wide Web—
except it doesn’t have to be like this.
&lt;!-- Task:         What was undertaken to address the need  --&gt;
&lt;!-- Object:       What the present document does or covers --&gt;
&lt;!-- Findings:     What the work done yielded or revealed   --&gt;
Although &lt;em&gt;trust&lt;/em&gt; remains an inherently human relationship,
machines can help us build and evolve our relationships
by handling the fiddly bits on our behalf.
&lt;!-- Conclusion:   What the findings mean for the audience  --&gt;
This liberates people to refocus on gaining mutual value from our relationships,
without the huge burden of their setup and maintenance.
&lt;!-- Perspectives: What the future holds, beyond this work  --&gt;
Everything starts with the realization
that &lt;em&gt;data&lt;/em&gt; technology is fundamentally &lt;em&gt;trust&lt;/em&gt; technology,
and thus a transversal layer within any ecosystem
rather than just the icing on the cake.&lt;/p&gt;&lt;p&gt;&lt;a href='https://ruben.verborgh.org/blog/2024/10/15/trust-takes-time/'&gt;Read more&amp;hellip;&lt;/a&gt;&lt;/p&gt;</content>
    <summary type="html">&lt;p&gt;Today’s websites and apps are built
to compensate for an absence of trust,
rather than to support its growth.
Customers and companies both understand that
human handshakes no longer scale in the digital age,
and surrender to their replacement
by a tap of the finger
on a button labeled &lt;q class="nobr"&gt;I accept&lt;/q&gt;.
While every handshake comes with an expectation of honesty,
this button never did:
we &lt;em&gt;know&lt;/em&gt; we are lying the moment we touch it,
as does the author of the legalese
no one expects anyone to read.
&lt;!-- Need:         Why something needed to be done at all   --&gt;
Navigating a trustless world
is a heavy price to pay
for the boundless freedoms of the World Wide Web—
except it doesn’t have to be like this.
&lt;!-- Task:         What was undertaken to address the need  --&gt;
&lt;!-- Object:       What the present document does or covers --&gt;
&lt;!-- Findings:     What the work done yielded or revealed   --&gt;
Although &lt;em&gt;trust&lt;/em&gt; remains an inherently human relationship,
machines can help us build and evolve our relationships
by handling the fiddly bits on our behalf.
&lt;!-- Conclusion:   What the findings mean for the audience  --&gt;
This liberates people to refocus on gaining mutual value from our relationships,
without the huge burden of their setup and maintenance.
&lt;!-- Perspectives: What the future holds, beyond this work  --&gt;
Everything starts with the realization
that &lt;em&gt;data&lt;/em&gt; technology is fundamentally &lt;em&gt;trust&lt;/em&gt; technology,
and thus a transversal layer within any ecosystem
rather than just the icing on the cake.&lt;/p&gt;</summary>
  </entry>
  <entry>
    <id>tag:ruben.verborgh.org,2024-05-30:/blog/2024/05/30/the-webs-data-triad/</id>
    <title type="html">The Web's data triad</title>
    <published>2024-05-30T17:30:00Z</published>
    <updated>2024-05-30T17:30:00Z</updated>
    <link rel="alternate" href="https://ruben.verborgh.org/blog/2024/05/30/the-webs-data-triad/" type="text/html"/>
    <content type="html">&lt;p&gt;There’s no single optimal way
to query permissioned data on the Web.
Data publication and consumption processes
are subject to multiple constraints,
and improvements in one dimension
often lead to compromises in others.
&lt;!-- Need:         Why something needed to be done at all   --&gt;
So if we cannot successfully complete the quest
for the perfect data interface,
what is a meaningful way to make progress?
&lt;!-- Task:         What was undertaken to address the need  --&gt;
Over the years,
I’ve been ripening a conceptual framework
to cast light upon such decisions
and their interactions within an ecosystem.
&lt;!-- Object:       What the present document does or covers --&gt;
In this blog post,
I describe the &lt;em&gt;Policy–Interface-Query triad&lt;/em&gt;,
or &lt;em&gt;PIQ triad&lt;/em&gt; for short.
It’s a tool to explore design trade-offs
in specifications or abstractions for data interfaces
within decentralized ecosystems such as Solid.
&lt;!-- Findings:     What the work done yielded or revealed   --&gt;
Despite—or thanks to—its simplicity,
&lt;!-- Conclusion:   What the findings mean for the audience  --&gt;
the PIQ triad aims to support us in our conversations
&lt;!-- Perspectives: What the future holds, beyond this work  --&gt;
to evolve decentralized data access technologies for the Web.&lt;/p&gt;&lt;p&gt;&lt;a href='https://ruben.verborgh.org/blog/2024/05/30/the-webs-data-triad/'&gt;Read more&amp;hellip;&lt;/a&gt;&lt;/p&gt;</content>
    <summary type="html">&lt;p&gt;There’s no single optimal way
to query permissioned data on the Web.
Data publication and consumption processes
are subject to multiple constraints,
and improvements in one dimension
often lead to compromises in others.
&lt;!-- Need:         Why something needed to be done at all   --&gt;
So if we cannot successfully complete the quest
for the perfect data interface,
what is a meaningful way to make progress?
&lt;!-- Task:         What was undertaken to address the need  --&gt;
Over the years,
I’ve been ripening a conceptual framework
to cast light upon such decisions
and their interactions within an ecosystem.
&lt;!-- Object:       What the present document does or covers --&gt;
In this blog post,
I describe the &lt;em&gt;Policy–Interface-Query triad&lt;/em&gt;,
or &lt;em&gt;PIQ triad&lt;/em&gt; for short.
It’s a tool to explore design trade-offs
in specifications or abstractions for data interfaces
within decentralized ecosystems such as Solid.
&lt;!-- Findings:     What the work done yielded or revealed   --&gt;
Despite—or thanks to—its simplicity,
&lt;!-- Conclusion:   What the findings mean for the audience  --&gt;
the PIQ triad aims to support us in our conversations
&lt;!-- Perspectives: What the future holds, beyond this work  --&gt;
to evolve decentralized data access technologies for the Web.&lt;/p&gt;</summary>
  </entry>
  <entry>
    <id>tag:ruben.verborgh.org,2023-11-10:/blog/2023/11/10/no-more-raw-data/</id>
    <title type="html">No more raw data</title>
    <published>2023-11-10T11:00:00Z</published>
    <updated>2023-11-10T11:00:00Z</updated>
    <link rel="alternate" href="https://ruben.verborgh.org/blog/2023/11/10/no-more-raw-data/" type="text/html"/>
    <content type="html">&lt;p&gt;Data without context is meaningless;
data without trust is useless.
&lt;q&gt;2017-12-18&lt;/q&gt; is nothing but a string—
until it becomes a birthdate,
a wedding,
or the moment a security camera registered you.
Handling such highly personal data
requires &lt;em&gt;trust&lt;/em&gt;.
When your personal data is shared with someone,
you must be able to trust that
they will only use it in the way you agreed to.
When someone receives your data,
they must be able to trust
that it is correct
and that they are allowed to use it for the intended purpose.
Auditors need to be able to
challenge and verify this trust relationship,
for example under GDPR.
&lt;!-- Need:         Why something needed to be done at all   --&gt;
These everyday scenarios highlight that
data ecosystems need trust
as an integral part of their DNA.
Unfortunately,
trust is not baked into our data interfaces today:
they only provide access to the raw data,
disregarding the context that is crucial to its correct treatment.
&lt;!-- Task:         What was undertaken to address the need  --&gt;
We need to standardize interfaces
that carry data in &lt;span class="nobr"&gt;a &lt;em&gt;trust envelope&lt;/em&gt;&lt;/span&gt;,
which encapsulates usage policies and provenance
to ensure that data can flow in more responsible ways.
&lt;!-- Object:       What the present document does or covers --&gt;
In this blog post,
I explore how this can work,
&lt;!-- Findings:     What the work done yielded or revealed   --&gt;
&lt;!-- Conclusion:   What the findings mean for the audience  --&gt;
and why they are a necessary change
in the way we exchange personal and other data.
&lt;!-- Perspectives: What the future holds, beyond this work  --&gt;&lt;/p&gt;&lt;p&gt;&lt;a href='https://ruben.verborgh.org/blog/2023/11/10/no-more-raw-data/'&gt;Read more&amp;hellip;&lt;/a&gt;&lt;/p&gt;</content>
    <summary type="html">&lt;p&gt;Data without context is meaningless;
data without trust is useless.
&lt;q&gt;2017-12-18&lt;/q&gt; is nothing but a string—
until it becomes a birthdate,
a wedding,
or the moment a security camera registered you.
Handling such highly personal data
requires &lt;em&gt;trust&lt;/em&gt;.
When your personal data is shared with someone,
you must be able to trust that
they will only use it in the way you agreed to.
When someone receives your data,
they must be able to trust
that it is correct
and that they are allowed to use it for the intended purpose.
Auditors need to be able to
challenge and verify this trust relationship,
for example under GDPR.
&lt;!-- Need:         Why something needed to be done at all   --&gt;
These everyday scenarios highlight that
data ecosystems need trust
as an integral part of their DNA.
Unfortunately,
trust is not baked into our data interfaces today:
they only provide access to the raw data,
disregarding the context that is crucial to its correct treatment.
&lt;!-- Task:         What was undertaken to address the need  --&gt;
We need to standardize interfaces
that carry data in &lt;span class="nobr"&gt;a &lt;em&gt;trust envelope&lt;/em&gt;&lt;/span&gt;,
which encapsulates usage policies and provenance
to ensure that data can flow in more responsible ways.
&lt;!-- Object:       What the present document does or covers --&gt;
In this blog post,
I explore how this can work,
&lt;!-- Findings:     What the work done yielded or revealed   --&gt;
&lt;!-- Conclusion:   What the findings mean for the audience  --&gt;
and why they are a necessary change
in the way we exchange personal and other data.
&lt;!-- Perspectives: What the future holds, beyond this work  --&gt;&lt;/p&gt;</summary>
  </entry>
  <entry>
    <id>tag:ruben.verborgh.org,2022-12-30:/blog/2022/12/30/lets-talk-about-pods/</id>
    <title type="html">Let's talk about pods</title>
    <published>2022-12-30T21:00:00Z</published>
    <updated>2022-12-30T21:00:00Z</updated>
    <link rel="alternate" href="https://ruben.verborgh.org/blog/2022/12/30/lets-talk-about-pods/" type="text/html"/>
    <content type="html">&lt;p&gt;Who decides what your Solid pod looks like?
For a long time,
the answer has been
&lt;q&gt;the first one who writes, decides&lt;/q&gt;.
That is,
the first app to sculpt documents and containers in your pod
determines where other apps need to look for data.
Unfortunately,
this creates an undesired dependency between apps,
which now have to agree amongst each other on how to store things.
Yet Solid promises apps
that will seamlessly and independently reuse data
in order to provide us with better and safer experiences.
At the heart of this contradiction is
that the mental model we’re using for Solid pods
no longer works.
This model restricts our solution space
and is a main reason why apps struggle to reuse each other’s data.
In this blog post,
I argue why we should stop thinking of a pod as a set of documents,
and start treating it as the hybrid graph it actually is.
By adjusting our perspective,
Solid apps can become more independent of variations in data—
and thus more powerful for us.&lt;/p&gt;&lt;p&gt;&lt;a href='https://ruben.verborgh.org/blog/2022/12/30/lets-talk-about-pods/'&gt;Read more&amp;hellip;&lt;/a&gt;&lt;/p&gt;</content>
    <summary type="html">&lt;p&gt;Who decides what your Solid pod looks like?
For a long time,
the answer has been
&lt;q&gt;the first one who writes, decides&lt;/q&gt;.
That is,
the first app to sculpt documents and containers in your pod
determines where other apps need to look for data.
Unfortunately,
this creates an undesired dependency between apps,
which now have to agree amongst each other on how to store things.
Yet Solid promises apps
that will seamlessly and independently reuse data
in order to provide us with better and safer experiences.
At the heart of this contradiction is
that the mental model we’re using for Solid pods
no longer works.
This model restricts our solution space
and is a main reason why apps struggle to reuse each other’s data.
In this blog post,
I argue why we should stop thinking of a pod as a set of documents,
and start treating it as the hybrid graph it actually is.
By adjusting our perspective,
Solid apps can become more independent of variations in data—
and thus more powerful for us.&lt;/p&gt;</summary>
  </entry>
  <entry>
    <id>tag:ruben.verborgh.org,2021-12-23:/blog/2021/12/23/reflections-of-knowledge/</id>
    <title type="html">Reflections of knowledge</title>
    <published>2021-12-23T11:00:00Z</published>
    <updated>2021-12-23T11:00:00Z</updated>
    <link rel="alternate" href="https://ruben.verborgh.org/blog/2021/12/23/reflections-of-knowledge/" type="text/html"/>
    <content type="html">&lt;p&gt;Web services emerged in the late 1990s as a way
to access specific pieces of remote functionality,
building on the standards-driven stability brought by the universal protocol
that HTTP was readily becoming.
Interestingly, the Web itself has drastically changed since.
During an &lt;a href="/articles/redecentralizing-the-web/"&gt;era of unprecedented centralization&lt;/a&gt;,
almost &lt;em&gt;all&lt;/em&gt; of our data relocated to remote systems,
which appointed Web APIs as the exclusive gateways
to our digital assets.
While the &lt;a href="/blog/2020/12/07/a-data-ecosystem-fosters-sustainable-innovation/"&gt;legal and socio-economic limitations&lt;/a&gt;
of such Big Data systems began painfully revealing themselves,
the window of opportunity for &lt;a href="/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/"&gt;decentralized data ecosystems&lt;/a&gt;
opened up wider than ever before.
The knowledge graphs of the future
are already emerging today,
and they’ll be so massively large and elusive
that they can never be captured by any single system—
and hence impossibly be exposed through any single API.
This begs the question of
how servers can provide flexible entry points
into this emerging Web-shaped knowledge ecosystem,
and how clients can sustainably interact with them.
This blog post describes the upcoming shift
from API integration to data integration,
why we assume the latter is the easier problem,
and what it fundamentally means to channel abstract knowledge
through concrete Web APIs.&lt;/p&gt;&lt;p&gt;&lt;a href='https://ruben.verborgh.org/blog/2021/12/23/reflections-of-knowledge/'&gt;Read more&amp;hellip;&lt;/a&gt;&lt;/p&gt;</content>
    <summary type="html">&lt;p&gt;Web services emerged in the late 1990s as a way
to access specific pieces of remote functionality,
building on the standards-driven stability brought by the universal protocol
that HTTP was readily becoming.
Interestingly, the Web itself has drastically changed since.
During an &lt;a href="/articles/redecentralizing-the-web/"&gt;era of unprecedented centralization&lt;/a&gt;,
almost &lt;em&gt;all&lt;/em&gt; of our data relocated to remote systems,
which appointed Web APIs as the exclusive gateways
to our digital assets.
While the &lt;a href="/blog/2020/12/07/a-data-ecosystem-fosters-sustainable-innovation/"&gt;legal and socio-economic limitations&lt;/a&gt;
of such Big Data systems began painfully revealing themselves,
the window of opportunity for &lt;a href="/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/"&gt;decentralized data ecosystems&lt;/a&gt;
opened up wider than ever before.
The knowledge graphs of the future
are already emerging today,
and they’ll be so massively large and elusive
that they can never be captured by any single system—
and hence impossibly be exposed through any single API.
This begs the question of
how servers can provide flexible entry points
into this emerging Web-shaped knowledge ecosystem,
and how clients can sustainably interact with them.
This blog post describes the upcoming shift
from API integration to data integration,
why we assume the latter is the easier problem,
and what it fundamentally means to channel abstract knowledge
through concrete Web APIs.&lt;/p&gt;</summary>
  </entry>
  <entry>
    <id>tag:ruben.verborgh.org,2020-12-07:/blog/2020/12/07/a-data-ecosystem-fosters-sustainable-innovation/</id>
    <title type="html">A data ecosystem fosters sustainable innovation</title>
    <published>2020-12-07T14:30:00Z</published>
    <updated>2020-12-07T14:30:00Z</updated>
    <link rel="alternate" href="https://ruben.verborgh.org/blog/2020/12/07/a-data-ecosystem-fosters-sustainable-innovation/" type="text/html"/>
    <content type="html">&lt;p&gt;We’re living in a data-driven economy,
and that won’t change anytime soon.
Companies, start-ups, organizations, and governments all require some of our data
to provide us with the services we want and need.
Unfortunately,
decades of Big Data thinking has led many companies to a consequential fallacy:
the belief that they need to harvest and maintain that personal data &lt;em&gt;themselves&lt;/em&gt;
in order to deliver their services
and thus survive in the data-driven economy.
This prompted a never-ending rat race,
dominated by a handful of large players
and driven by a deeply flawed notion of “winning”,
with as a result that
most people and companies
collectively end up losing much more than they put in.
Pointless data greed has falsified competition
and stifled innovation
from the moment data collection became more important
than quality of experience.
A way out of this dead end
is to put people fully in control of their own data
by equipping them with a &lt;em&gt;personal data vault&lt;/em&gt;.
Vaults enable us to break the standstill,
as they re-level the playing field
by giving all parties equal chances to access data
under people’s control.
Halting data harvesting is,
paradoxically,
how companies can leverage &lt;em&gt;more&lt;/em&gt; data towards their services instead of &lt;em&gt;less&lt;/em&gt;.
Yet they won’t own that data—
and in a sustainable ecosystem, there’s no need to.
In this post,
I dive into the surprising economics
of an overdue data revolution.&lt;/p&gt;&lt;p&gt;&lt;a href='https://ruben.verborgh.org/blog/2020/12/07/a-data-ecosystem-fosters-sustainable-innovation/'&gt;Read more&amp;hellip;&lt;/a&gt;&lt;/p&gt;</content>
    <summary type="html">&lt;p&gt;We’re living in a data-driven economy,
and that won’t change anytime soon.
Companies, start-ups, organizations, and governments all require some of our data
to provide us with the services we want and need.
Unfortunately,
decades of Big Data thinking has led many companies to a consequential fallacy:
the belief that they need to harvest and maintain that personal data &lt;em&gt;themselves&lt;/em&gt;
in order to deliver their services
and thus survive in the data-driven economy.
This prompted a never-ending rat race,
dominated by a handful of large players
and driven by a deeply flawed notion of “winning”,
with as a result that
most people and companies
collectively end up losing much more than they put in.
Pointless data greed has falsified competition
and stifled innovation
from the moment data collection became more important
than quality of experience.
A way out of this dead end
is to put people fully in control of their own data
by equipping them with a &lt;em&gt;personal data vault&lt;/em&gt;.
Vaults enable us to break the standstill,
as they re-level the playing field
by giving all parties equal chances to access data
under people’s control.
Halting data harvesting is,
paradoxically,
how companies can leverage &lt;em&gt;more&lt;/em&gt; data towards their services instead of &lt;em&gt;less&lt;/em&gt;.
Yet they won’t own that data—
and in a sustainable ecosystem, there’s no need to.
In this post,
I dive into the surprising economics
of an overdue data revolution.&lt;/p&gt;</summary>
  </entry>
  <entry>
    <id>tag:ruben.verborgh.org,2019-06-17:/blog/2019/06/17/shaping-linked-data-apps/</id>
    <title type="html">Shaping Linked Data apps</title>
    <published>2019-06-17T11:00:00Z</published>
    <updated>2019-06-17T11:00:00Z</updated>
    <link rel="alternate" href="https://ruben.verborgh.org/blog/2019/06/17/shaping-linked-data-apps/" type="text/html"/>
    <content type="html">&lt;p&gt;Ever since &lt;a href="https://www.youtube.com/watch?v=JGwWNGJdvx8"&gt;Ed Sheeran’s 2017 hit&lt;/a&gt;,
I just can’t stop thinking about shapes.
It’s more than the earworm though:
2017 is the year in which I got deeply involved with &lt;a href="/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/"&gt;Solid&lt;/a&gt;,
and also when the &lt;a href="https://www.w3.org/TR/shacl/"&gt;SHACL&lt;/a&gt; recommendation for shapes was published.
The problem is a very fundamental one:
Solid promises the separation of data and apps,
so we can choose our apps
independently of where we store our data.
The apps &lt;em&gt;you&lt;/em&gt; choose
will likely be different from &lt;em&gt;mine&lt;/em&gt;,
yet we want to be able to interact with each other’s data.
Building such decentralized Linked Data apps
necessitates a high level of interoperability,
where data written by one app
needs to be picked up by another.
Rather than relying on the more heavy Semantic Web machinery of ontologies,
I believe that &lt;em&gt;shapes&lt;/em&gt; are the right way forward—
without throwing the added value of links and semantics out of the window.
In this post,
I will expand on the thinking that emerged
from working with Tim Berners-Lee
on the &lt;a href="https://www.w3.org/DesignIssues/Footprints.html"&gt;Design Issue on Linked Data shapes&lt;/a&gt;,
and sketch the vast potential of shapes
for tackling crucial problems in flexible ways.&lt;/p&gt;&lt;p&gt;&lt;a href='https://ruben.verborgh.org/blog/2019/06/17/shaping-linked-data-apps/'&gt;Read more&amp;hellip;&lt;/a&gt;&lt;/p&gt;</content>
    <summary type="html">&lt;p&gt;Ever since &lt;a href="https://www.youtube.com/watch?v=JGwWNGJdvx8"&gt;Ed Sheeran’s 2017 hit&lt;/a&gt;,
I just can’t stop thinking about shapes.
It’s more than the earworm though:
2017 is the year in which I got deeply involved with &lt;a href="/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/"&gt;Solid&lt;/a&gt;,
and also when the &lt;a href="https://www.w3.org/TR/shacl/"&gt;SHACL&lt;/a&gt; recommendation for shapes was published.
The problem is a very fundamental one:
Solid promises the separation of data and apps,
so we can choose our apps
independently of where we store our data.
The apps &lt;em&gt;you&lt;/em&gt; choose
will likely be different from &lt;em&gt;mine&lt;/em&gt;,
yet we want to be able to interact with each other’s data.
Building such decentralized Linked Data apps
necessitates a high level of interoperability,
where data written by one app
needs to be picked up by another.
Rather than relying on the more heavy Semantic Web machinery of ontologies,
I believe that &lt;em&gt;shapes&lt;/em&gt; are the right way forward—
without throwing the added value of links and semantics out of the window.
In this post,
I will expand on the thinking that emerged
from working with Tim Berners-Lee
on the &lt;a href="https://www.w3.org/DesignIssues/Footprints.html"&gt;Design Issue on Linked Data shapes&lt;/a&gt;,
and sketch the vast potential of shapes
for tackling crucial problems in flexible ways.&lt;/p&gt;</summary>
  </entry>
  <entry>
    <id>tag:ruben.verborgh.org,2018-12-28:/blog/2018/12/28/designing-a-linked-data-developer-experience/</id>
    <title type="html">Designing a Linked Data developer experience</title>
    <published>2018-12-28T15:30:00Z</published>
    <updated>2018-12-28T15:30:00Z</updated>
    <link rel="alternate" href="https://ruben.verborgh.org/blog/2018/12/28/designing-a-linked-data-developer-experience/" type="text/html"/>
    <content type="html">&lt;p&gt;While the Semantic Web community was fighting its own internal battles,
we failed to gain traction
with the people who build apps that are actually used:
&lt;em&gt;front-end developers&lt;/em&gt;.
Ironically,
Semantic Web enthusiasts have failed to focus on the &lt;em&gt;Web&lt;/em&gt;;
whereas our technologies are delivering results
in specialized back-end systems,
the promised intelligent end-user apps are not being created.
&lt;span class="nobr"&gt;Within the &lt;a href="https://solid.inrupt.com/"&gt;Solid&lt;/a&gt;&lt;/span&gt; ecosystem
for decentralized Web applications,
Linked Data and Semantic Web technologies play a crucial role.
Working intensely on Solid the past year,
I realized that designing a fun &lt;em&gt;developer experience&lt;/em&gt;
will be crucial to its success.
Through dialogue with front-end developers,
I created a couple of JavaScript libraries
for easy interaction with complex Linked Data—
without having to know RDF.
This post introduces the core React components for Solid
along with the LDflex query language,
and lessons learned from their design.&lt;/p&gt;&lt;p&gt;&lt;a href='https://ruben.verborgh.org/blog/2018/12/28/designing-a-linked-data-developer-experience/'&gt;Read more&amp;hellip;&lt;/a&gt;&lt;/p&gt;</content>
    <summary type="html">&lt;p&gt;While the Semantic Web community was fighting its own internal battles,
we failed to gain traction
with the people who build apps that are actually used:
&lt;em&gt;front-end developers&lt;/em&gt;.
Ironically,
Semantic Web enthusiasts have failed to focus on the &lt;em&gt;Web&lt;/em&gt;;
whereas our technologies are delivering results
in specialized back-end systems,
the promised intelligent end-user apps are not being created.
&lt;span class="nobr"&gt;Within the &lt;a href="https://solid.inrupt.com/"&gt;Solid&lt;/a&gt;&lt;/span&gt; ecosystem
for decentralized Web applications,
Linked Data and Semantic Web technologies play a crucial role.
Working intensely on Solid the past year,
I realized that designing a fun &lt;em&gt;developer experience&lt;/em&gt;
will be crucial to its success.
Through dialogue with front-end developers,
I created a couple of JavaScript libraries
for easy interaction with complex Linked Data—
without having to know RDF.
This post introduces the core React components for Solid
along with the LDflex query language,
and lessons learned from their design.&lt;/p&gt;</summary>
  </entry>
  <entry>
    <id>tag:ruben.verborgh.org,2017-12-20:/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/</id>
    <title type="html">Paradigm shifts for the decentralized Web</title>
    <published>2017-12-20T11:00:00Z</published>
    <updated>2017-12-20T11:00:00Z</updated>
    <link rel="alternate" href="https://ruben.verborgh.org/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/" type="text/html"/>
    <content type="html">&lt;p&gt;Most Web applications today follow the adage “your data for my services”.
They motivate this deal from both a technical perspective
&lt;em&gt;(how could we provide services without your data?)&lt;/em&gt;
and a business perspective
&lt;em&gt;(how could we earn money without your data?)&lt;/em&gt;.
Decentralizing the Web means that
people gain the ability to store their data wherever they want,
while still getting the services they need.
This requires major changes
in the way we develop applications,
as we migrate from a closed back-end database
to the open Web as our data source.
In this post,
I discuss three paradigm shifts
a decentralized Web brings,
demonstrating that decentralization is about much more
than just controlling our own data.
It is a fundamental rethinking
of the relation between data and applications,
which—if done right—will accelerate creativity and innovation
for the years to come.&lt;/p&gt;&lt;p&gt;&lt;a href='https://ruben.verborgh.org/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/'&gt;Read more&amp;hellip;&lt;/a&gt;&lt;/p&gt;</content>
    <summary type="html">&lt;p&gt;Most Web applications today follow the adage “your data for my services”.
They motivate this deal from both a technical perspective
&lt;em&gt;(how could we provide services without your data?)&lt;/em&gt;
and a business perspective
&lt;em&gt;(how could we earn money without your data?)&lt;/em&gt;.
Decentralizing the Web means that
people gain the ability to store their data wherever they want,
while still getting the services they need.
This requires major changes
in the way we develop applications,
as we migrate from a closed back-end database
to the open Web as our data source.
In this post,
I discuss three paradigm shifts
a decentralized Web brings,
demonstrating that decentralization is about much more
than just controlling our own data.
It is a fundamental rethinking
of the relation between data and applications,
which—if done right—will accelerate creativity and innovation
for the years to come.&lt;/p&gt;</summary>
  </entry>
</feed>

