Reflections of knowledge:
Web APIs for decentralized knowledge graphs

Ruben Verborgh, Ghent Universityimec

The Knowledge Graph Conference, 4 May 2022

Based on my blog post Reflections of knowledge

Reflections of knowledge

Web APIs for decentralized knowledge graphs

Ruben Verborgh

Ghent University – imec

[Plato's allegory of the cave]

How can Web clients interact with
decentralized knowledge graphs?

The sum of multiple knowledge graphs
is an even bigger knowledge graph.

The sum of multiple Web APIs
is an even bigger mess.

Web APIs provide access to
remote data or functionality.

Common misconceptions prevent us from
designing effective knowledge graph APIs.

  1. Client abstractions require server abstractions.
  2. Querying requires dedicated query interfaces.
  3. One universal API can satisfy all use cases.

Client abstractions are not limited
to server-side abstractions.

The label query API is meaningless:
every API offers some kind of query.

No single universal Web API exists
to satisfy all use cases.

On the decentralized Web of the future,
every person has their own data pod.

[the Solid logo]

Data created by or about a person will be
stored in their personal knowledge graph.

Apps over decentralized knowledge graphs
need to blend data from many sources.

Decentralized apps require query:
read/write access to a knowledge graph.

[a browser app needs access to knowledge]

Too big and complex for any single app,
the full graph is emulated via small parts.

[apps operate parts of the knowledge graph]

Access to single-source knowledge parts
can be provided through a Web API.

[accessing knowledge hosted on a single server]

Document-oriented Web APIs pretend
the graph is structured across documents.

[accessing knowledge through a single JSON API]

Query-oriented Web APIs combine data
of many documents of a document API.

[GraphQL APIs can access multiple conceptual resources]

Let’s examine the consequences of
decentralizing the knowledge graph.

[an application needs to access a knowledge graph that is distributed across multiple servers]

Every source exposes its part of the graph
through a Linked Data Web API.

[each server exposes an RDF API]

Several different Linked Data APIs exist,
each with vastly different characteristics.

[RDF can be exposed through different APIs]

Each source can expose its same graph
through multiple different Web APIs.

[each server might expose the same knowledge through multiple APIs]

No single query-oriented API can help us,
since there is no single server to attach to.

[we cannot attach a GraphQL API to any single server when the data resides in multiple servers]

The app can still be written using queries:
a library translates into HTTP requests.

[a client-side library translates GraphQL queries from the app into HTTP requests for different APIs and servers]

Query is crucial to app sustainability since
it allows apps to make fewer assumptions.

Moving to query means transitioning
from API integration to data integration.

Web APIs are a means to an end: we need
client-side knowledge graph tooling.

  1. Client and API abstractions can differ.
    • Reusable client libraries separate the what from the how.
  2. Every Web API is a query API.
    • Every Web client is a query client.
      (whether you realize it or not)
  3. No single Web API is the final answer.
    • Design APIs as part of an ecosystem:
      how can APIs help—rather than replace—intelligent clients?
[Plato's allegory of the cave]

Reflections of knowledge

Web APIs for decentralized knowledge graphs