The Solid vision aims to make data independent of applications through technical specifications, which detail how to publish and consume permissioned data across multiple autonomous locations called “pods”. The current document-centric interpretation of Solid, wherein a pod is a single hierarchy of Linked Data documents, cannot fully realize this independence. Applications are left to define their own APIs within the Solid Protocol, leading to fundamental interoperability problems and the need for associated workarounds. The long-term vision for Solid is confounded with the concrete HTTP interface to pods today, leading to a narrower solution space to address core issues. We examine the mismatch between the vision and its prevalent document-centric interpretation, and propose a reconciliatory graph-centric interpretation wherein a pod is a hybrid, contextualized knowledge graph. In this article, we contrast the existing and proposed interpretations in terms of how they support the Solid vision. We argue that the graph-centric interpretation can improve pod access through different Web APIs that act as views into the knowledge graph. We show how the latter interpretation provides improved opportunities for storage, publication, and querying of decentralized data in more flexible and sustainable ways. These insights are crucial to reduce the dependency of Solid apps on implicit API semantics and local assumptions about the shape and organization of data and the resulting performance. The suggested broader interpretation can guide Solid through its evolution into a heterogeneous yet interoperable ecosystem that better supports the diverging read/write data access patterns of different use cases.
Data privacy and control have lost ground on today’s Web. User-generated data is stored in central‐
ized data silos, in which people have neither the control nor the knowledge to manage how their data is
being used [
To this end, Solid introduces the concept of a pod as an online data space for an individual to control and manage their data on the Web. Together, these pods form a decentralized Solid ecosystem, from which applications can directly integrate data from people’s Solid pods, after receiving their permission. This contrasts with current Web applications, where this data first had to be collected in a centralized location, after which the platform-specific API had to be integrated, where all the while user control is at the mercy of the platforms maintaining the data.
In order to separate data from applications, the semantic contents of the data must be captured such
that they can be accurately interpreted and reused in different contexts. Semantics allow applications to
interpret data without requiring specific knowledge encoded in the API over which the data is re‐
© 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
trieved. A key driver is the use of the Resource Description Framework (RDF) [
Unfortunately, we observe a significant gap between theory and practice: current Solid apps do not succeed in API-independent reuse of data across use cases. Rather than only relying on the data and its semantics, apps resort to implicit knowledge about how this data is structured across documents in a pod’s Web API. Furthermore, different use cases impose conflicting requirements on that structure in order to satisfy their own constraints. As such, app developers struggle to make sustainable decisions on how to structure data for reuse, since their individual choices impact the interoperability of the en‐ tire ecosystem.
In this article, we identify the root cause of this interoperability problem as the mismatch between Solid’s current single hierarchical API and the modeling requirements of real-world use cases. We de‐ scribe the properties of this document-centric interpretation of a pod, and introduce a graph-centric in‐ terpretation that can bridge differences between use cases. We compare both interpretations, explain the consequences for concrete Solid implementations, and argue why we consider the graph-centric in‐ terpretation a more sustainable candidate to realize the Solid vision of data and application indepen‐ dence under control of the user.
In order to pinpoint the concrete differences between interpretations, we introduce two small use cases that we will carry throughout the paper.
The contacts use case is a rather trivial example, but we introduce it to evidence that even very sim‐ ple use cases can expose issues in the interpretation of a pod. The implication is thus that, if a certain interpretation cannot adequately handle the contacts use case, then it is likely to break more complex cases as well. The case is as follows: !"The data consists of a set of contacts, each of which have associated attributes such as name, ad‐ dress, email, phone number, date of birth. !"An address book app provides read and write access to each attribute of a contact, and allows creat‐ ing new contacts. !"A birthday app shows daily reminders of contacts with upcoming birthdays, and allows editing birthdays and adding new ones.
The medical use case is conceptually simple, but it involves highly sensitive data. Its purpose is to demonstrate that issues identified in the contacts use case easily generalize to more core complex data and real-world problems. In this use case, the user is a patient storing the following data: !"A set of medical records reflecting blood test results, with records containing various vitamin levels as well as HIV status results. !"A set of heart rate and blood pressure measurements, captured by the user’s wearable device.
Before describing the interpretations of a Solid pod, we start with a couple of definitions that we will
use as building blocks throughout the article.
!"We consider a protocol to be a generic set of rules for data transmission between systems.
#"The HyperText Transfer Protocol (HTTP) [
#"The WebID [
#"Solid-OIDC [
Let us exemplify some of these definitions through our use cases: !"An HTTP interface at https://sasha.pod/ implements the Solid Protocol when its containers and documents follow the interaction rules, and when it correctly authenticates users using their WebID and applies authorization to each resource. !"A Web API within https://sasha.pod/ structures documents in containers.
#"Contacts are stored in https://sasha.pod/people/ as individual documents: $"https://sasha.pod/people/sasha.ttl $"https://sasha.pod/people/lucian.ttl #"Medical records are stored in https://sasha.pod/private/acme-hospital/ by date, such as: $"https://sasha.pod/private/acme-hospital/2022/10/15/test-results.ttl !"The WebID https://sasha.pod/people/sasha#me identifies a person named Sasha. !"The agent identified by https://sasha.pod/people/sasha#me is allowed to access all documents on https://sasha.pod/.
This section discusses the currently prevalent interpretation of a pod, which is document-centric.
As described in Section 3, the Solid Protocol models interactions with data as recursive containers with RDF and non-RDF documents. When a server offers this protocol, clients of this server can itera‐ tively define a Web API by creating containers and documents.
The document-centric interpretation assumes that the structure and contents of the Web API, which a pod exposes through the Solid Protocol, is that pod in its entirety. Within this interpretation, the com‐ plete state of the pod is thus equivalent to the single Web API through which it is available; the source of truth is solely that specific Web API. That brings us to the following definition:
In the document-centric interpretation, each Solid pod is a single specific hierarchical structure of containers and documents exposed through the Solid Protocol, where data and access control rules are stored in specific RDF and non-RDF documents within that hierarchy.
For example, a Solid pod would be fully defined by the following hierarchy and the contents of its documents: !"container https://sasha.pod/ #"RDF document .acl (for access control) #"container people/ $"RDF document .acl (for access control) $"RDF document amal.ttl $"RDF document lucian.ttl $"… #"container private/ $"RDF document .acl (for access control) $"container medical-records/ $"non-RDF document 2022-09-15.pdf $"non-RDF document 2022-10-15.pdf $"… #"…
In the above example, the access control document https://sasha.pod/private/.acl could contain WAC rules such that only the agent https://sasha.pod/people/sasha#me is allowed to access the con‐ tainer https://sasha.pod/private/ and below.
The above document-centric definition of a pod leaves several degrees of freedom as to how the pod is structured and how the resulting structure is interpreted. We now describe how today’s Solid apps handle those degrees of freedom in practice.
Importantly, the current Solid technical reports [
As a consequence, client-side applications have to invent their own (sub-)API within the pod’s URL
space available through the Solid Protocol, by defining a certain container structure and data distribu‐
tion across documents within this structure. We observe two kinds of behavior:
!"Some apps use hard-coded paths to certain containers (e.g., /contacts/) or documents (e.g.,
/profile/card).
!"Some apps use link traversal, which means they find the URLs of documents and containers by fol‐
lowing links from the user’s WebID profile document and/or via another index [
We also observe hybrid behavior, for instance where an initial path is obtained via traversal (e.g., /private/medical/), but deeper relative paths are hardcoded (e.g., /private/medical/2022/10/). In particular, link traversal is bootstrapped via hardcoded paths: if no link exists to the certain kind of data, then a specific document is created at a hardcoded path and then linked from a profile or index for future usage.
From the way current apps organize data in RDF documents, we can observe the meaning they as‐
cribe to such a document. Noting that Solid typically uses RDF 1.0 documents (so only triples, and not
quads as in RDF 1.1), the occurrence of an RDF triple in a document seems to carry various degree of
meaning with regard to the following aspects:
!"(implicit) Context: the occurrence of certain triples within the same document often implies that
they are somehow interrelated, and that these triples somehow relate to the document. This topical
relation is sometimes visible within certain triples, whose subject (e.g., https://sasha.pod/people
/sasha#me) defines a URL fragment (e.g., #me) on the document identifier (e.g., https://
sasha.pod/people/sasha).
!"(explicit) Policy: both the WAC [
We remark that of these 5 aspects, only the policy on the document is modelled explicitly. The con‐ text is implicitly assumed because triples occurring in the same place were usually created by the same or related write operations, and because those triples are necessarily read together by apps. The prove‐ nance and trust are similarly derived from implicit assumptions about a shared origin, and the knowl‐ edge of specific policies and thus agents that could have written to the document. Notably, the fact that an identifier (e.g., https://sasha.pod/people/) is contained within a certain pod root container (e.g., https://sasha.pod/) does encode some explicit provenance about the document and its triples (e.g., “they were found in Sasha’s pod”), but not necessarily about its creator or level of trust (e.g., multiple actors might have write access to the document). Finally, the performance is typically based on edu‐ cated guesses, but seldom the result of actual performance measurements.
Many applications encounter practical limitations when the data they require happens to be structured across multiple documents in the main API. In an attempt to address such cases, alternative Web APIs were proposed.
One proposal [
Crucially, such alternative APIs are always derived from the main API, which is equivalent to the pod in the document-centric interpretation. The derived APIs thereby unavoidably inherit some of the ex‐ plicit and implicit modeling aspects from the document-based main API. Concretely, the direct deriva‐ tion from the main API manifests itself in the choice of the data model for the SPARQL and QPF inter‐ faces. The RDF 1.1 quads they expose are constructed by loading the triples from each document, adding as a graph component the URL of that document. The following example quad reflects this: !"subject: https://sasha.pod/people/sasha#me !"predicate: https://example.org/ontology#birthDate !"object: "1984-04-03"
Its components signify that there exists a triple with that specific subject, predicate, and object in the document with URL https://sasha.pod/private/medical/2022/10/15.ttl. In other words, the document-centric interpretation of a pod considers the birthdate statements’ occurrence in this specific document on the pod to be an integral part of the statement itself.
In this section, we will examine and critique the consequences of the document-centric interpretation of a pod. Specifically, we study the limitations of the single hierarchy it causes (Subsection 4.1), and the effects of the implicit semantics in its structure (Subsubsection 4.3.1) and documents (Subsubsection 4.3.2). While some consequences could in theory be mitigated by alternative APIs (Subsubsection 4.3.3), the effectiveness thereof is hindered by the necessity of those alternatives to de‐ rive from the main API structure.
Each app needs to have a single consistent hierarchy to serialize its data, which does not reflect the complex nature of real-world organization. For instance, the address book app could organize people in categories such as /contacts/work/ and /contacts/sports/, which leads to duplication when a per‐ son’s colleague is also a member of their badminton team. A similar situation occurs when we need to decide whether to group health measurements by date (/medical/2022/10/15.ttl) or by topical evolu‐ tion over time (/medical/vitamine-d-levels.ttl)
Hierarchical organizations are thus either constrained by their necessity to commit to a single repre‐ sentation of the real world, or in need of mechanisms to cope with the effects of data duplication or vir‐ tualization. An alternative API circumvents some of these limitations when it comes to reading, al‐ though the provenance and trust of the resulting responses are even less explicitly defined than in the main API. Writing is still fully coupled to the destination documents in the main API, since the quad components of each triple need to contain a specific document URL.
The document-centric view of the Solid Protocol does not inherently provide interoperability, because apps are still responsible for determining the specific API that defines the document and container structure they will access. To make matters worse, different apps and use cases can have competing in‐ terests that lead them to prefer one API structure over another.
For example, interoperability requires the address book and birthday apps to use the same data, and hence to store it in the same place, such as the /people/ container. However, their preferences regard‐ ing the organization of that container vary. The address book app, which lets the user edit contacts one by one, has a context and performance incentive to place all contact attributes in a single RDF docu‐ ment per contact, leading to an organization such as: !"/people/work/dani.ttl !"/people/work/kiran.ttl !"/people/personal/kai.ttl !"/people/personal/luka.ttl !"…
In contrast, the birthday app aims to quickly determine which celebrations are coming up, probably preferring a structure more like: !"/people/work/birthdays.ttl
Or possibly even: !"/people/birthdays/january.ttl !"…
Similarly, whether heart rate and blood pressure measurements are organized by date or by evolution over time, depends on the specifics of a current use case.
Context- and performance-based grouping are trade-offs that can be overcome with compromises, such as accepting that certain use cases will be slower than others. Unfortunately, the imposed group‐ ing of multiple different aspects in the same document can also lead to more sensitive and insurmount‐ able conflicts for the policy, provenance, and trust aspects.
Since the coupling of policies to document organization provides the only mechanism of control in the document-centric view, some use cases with conflicting requirements cannot effectively be realized today. For example, assume that the address book app indeed organizes contacts as one person per doc‐ ument: !"/people/dani.ttl !"/people/kiran.ttl !"…
In that case, the birthday app would be able to read (and needing to parse) people’s personal details such as addresses and phone numbers, whereas the expectation is that it should only access names and birthdays.
Insurmountable conflicts become even more apparent with the medical use case. The results of a given blood test might be stored in a single document, and thus have a single policy boundary associ‐ ated with it. If that test result contains both vitamin levels and an HIV status, then the document-based access control prevents users from only giving access to their vitamin levels.
The fact that conflicting requirements between aspects would necessitate the complexity of copies, flags a strong limitation of any single hierarchical API. One partial solution is to split these pieces of data into different documents, but this results in suboptimal boundaries for purposes of context, prove‐ nance, and trust. Users thus find themselves torn between giving apps too much access, or having to deal with overly granular control—in the extreme case causing situations that necessitate managing micro-documents with only one or a handful of triples. Whilst the degrees of freedom in the Solid Protocol allows for any such structures, the resulting API would be highly impractical for humans and machines alike. Another solution involves creating and maintaining a copy of the document with a sub‐ set of the data, which—in addition to the overhead of managing such copies—would also generate a diff‐ fferent associated context, provenance, and trust—especially if writing to such derived documents is needed. Furthermore, all these aspects would necessarily be reflected in any derived APIs, which are tied to the main API’s document-based structure and boundaries.
We conclude that document-centric pods inherently contain a large amount of implicit semantics in their API structure, hindering the realization of the data and application independence that is para‐ mount to the Solid vision. Some semantics that are supposed to be entangled with the data are in prac‐ tice assumed by the API, the construction of which happens in an uncoordinated way over time. The re‐ sulting spontaneous contracts are not made explicit by a single app, nor shared across multiple apps, meaning that interoperating apps have to be coded against each other rather than against the data, cre‐ ating undesired inter-application coupling.
In this section, we give the concept of a Solid pod a new interpretation, which is graph-centric.
We start from the limitations of the document-centric pod interpretation, which essentially assumes the Web API exposed by a pod to be equivalent to the pod itself. On the one hand, we acknowledge the universality and simplicity of document-based APIs, and in particular of the Solid Protocol, which offers the building blocks to construct such APIs with the appropriate authentication and authorization. On the other hand, we showed concrete evidence in Subsection 4.4 that no single such hierarchy is able to reconcile the conflicting constraints of different use cases, especially given that core aspects such as policies and provenance can only be applied at a document-level granularity.
While we recognize the importance of document-based Web APIs, we also observe that the simulta‐ neous support for multiple use cases clearly requires multiple perspectives into the same data, each sat‐ isfying the constraints of particular cases. Even though the creation of multiple views has been att‐ ttempted for Solid pods with SPARQL and QPF interfaces, their direct derivation from the main API still leads them to inherit that API’s mismatched constraints on the modeling of policies, provenance, and trust.
In other words, aiming to derive richer views from the main pod API is akin to using a real-world ob‐ ject’s two-dimensional projection to derive alternate two-dimensional projections of that same object. Because any two-dimensional projection is inherently designed to discard information of the original, the creation of complementary alternative projections actually requires the object’s underlying threedimensional reality. The two-dimensional projection was only ever meant as a helpful approximation of the three-dimensional object.
Translating this dimensionality metaphor to the world of pods, we conclude that today’s single hier‐ archical API to a pod serves as a proxy for the underlying knowledge graph formed by the union of the pod’s interlinked RDF documents—except that this union cannot adequately be reproduced because sig‐ nificant parts of its semantics are being discarded during its exposure in a specific API. Solid applica‐ tions looking to leverage the potential of this larger Linked Data knowledge graph, will thus always be hindered by the limitations of one arbitrarily formed document API acting as its sole access gateway.
Given the above observations within the document-centric interpretation, we create a new interpre‐ tation that shifts the function of a pod’s main API from being the pod itself to acting as one of many possible interfaces to an underlying knowledge graph, which is the pod. The source of truth is a knowl‐ edge graph consisting of documents as well as RDF statements, from which multiple Web APIs can be derived. Hence, no particular API is more prominent than any other. We define this as follows:
In the graph-centric interpretation, each Solid pod is a hybrid, contextualized knowledge graph, wherein “hybrid” indicates first-class support for both documents and RDF statements, and “contextual‐ ized” the ability to associate each of its individual documents and statements with metadata such as policies, provenance, and trust.
For example, the pod https://sasha.pod/ could be a hybrid knowledge graph consisting of: !"RDF triples expressing contact details of https://sasha.pod/people/amal#me !"RDF triples expressing contact details of https://sasha.pod/people/lucian#me !"a PDF document containing medical images dated 2022-09-15 !"RDF triples representing a blood test result dated 2022-10-15 !"…
Examples of associated metadata within this pod are: !"The RDF triples about Amal form a shared context with specific trust and provenance. !"A policy states that professional contact names can be publicly readable. !"A policy states that contacts’ phone numbers are only visible to Sasha. !"The provenance of Lucian’s phone number is a specific email. !"We trust the test result of 2022-10-15 is unmodified and accurate, because it is certified by a medical professional.
Below is one possible Web API on top of this pod that conforms to the Solid Protocol: !"container https://sasha.pod/ #"container contacts/work/ $"RDF document .acl (for access control) $"RDF document amal.ttl $"RDF document lucian.ttl $"… #"…
$"… #"…
The same pod could simultaneously offer other Web APIs through the Solid Protocol: !"container https://sasha.pod/ #"container people/birthdays/ $"RDF document .acr (for access control) $"RDF document january.ttl $"RDF document february.ttl
Furthermore, the pod could have SPARQL and QPF interfaces on top of its knowledge graph, in addi‐ tion to other Web APIs.
Importantly, the “hybrid” and “contexualized” qualifiers are equally important as the “knowledge graph” term in the definition. This means that off-the-shelf triplestores or quadstores do not qualify as implementations of a pod. Whereas they could possibly be used as physical storage for such a pod (see Subsection 6.1), any implementation requires native support for documents and metadata.
The ability to generate multiple Web APIs that act as views on the data is required functionality for the pod. Below, we discuss how the aspects from Subsubsection 4.3.2 are modeled in the pod and the re‐ sulting APIs. !"Context: Each triple or document in the pod can be associated with multiple contexts. For instance, users could assign triples to specific resources in Web APIs (“this triple is exposed in the documents /records/2022-15-10.ttl and /records/2022-15-10-summary.ttl”), or smaller ad-hoc groupings could be created (“these triples have a topical relationship”). An API can reflect this context through its resource structure, or by including explicit metadata in its response. !"Policy: Policies can be assigned to resources in one of the Web APIs and/or to selections of triples. In case policies are assigned to triples, their inclusion in a response can be conditionally determined by whether or not the requesting agent has access. !"Provenance: Provenance can be associated with individual triples or groups of triples, similar to how generic context is modeled. !"Trust: Trust can be expressed either as a function of provenance, or explicitly assigned to (groups of) triples, like context. !"Performance: The performance is no longer a function of the pod structure itself, but rather re‐ flected in how well a specific API matches the access patterns of a given use case. In other words, performance concerns need to be addressed by defining relevant APIs on top of the underlying knowledge graph.
The implementation of those aspects differs from the document-centric interpretation in two crucial ways: 1. All 5 aspects are modeled explicitly: either as metadata in the knowledge graph that can then be re‐ flected in an API (for context, policy, provenance, and trust), or in the definition of a specific API (for performance). 2. Each aspect can have a different granularity. For instance, a certain group of triples could share the same provenance, but have different policies applied to them.
We will now revisit how the graph-centric interpretation addresses the mismatches of the documentcentric interpretation (Subsection 4.4).
Applications are no longer restricted to a single hierarchy for modeling information, because the view-based approach allows overlapping resources without requiring copies.
For example, if a person is both a colleague and a badminton player, their details can be available through both the documents /contacts/work/amal.ttl and /contacts/sports/amal.ttl, wherein the containers /contacts/work/ and /contacts/sports/ can have different policies associated with them. From the perspective of a consumer, neither document is more authoritative than the other, as they are generated from the same triples in the underlying knowledge graph. Similarly, medical records can be organized by both date (/medical/2022/10/15.ttl) and topical evolution (/medical/heartrate-2021-2022.ttl), allowing them to have different provenance and trust.
Every app can choose the modeling that best fit its use case, as the same knowledge graph can be exposed through multiple Web APIs. This allows applications to find the APIs that best match their ac‐ cess patterns or, conversely, the pod to define APIs based on the needs of use cases.
For example, the address book app can be built using an API that organizes the attributes of a person
in a single document, whereas the birthday app can group all birthdays together. That way, neither ap‐
plication downloads more data than necessary. Similarly, medical data can be grouped depending on the
analyses that will be performed. Note that exact matches of access patterns to APIs will not always be
possible nor desired; the idea is rather to offer a couple of core APIs that minimize overhead across a
number of use cases [
Finally, the granularity of resources in a given API can be aligned with the granularity of policies, since this granularity does not have to be shared with the other aspects.
For example, the birthday app could have a read/write API to the contacts that does not include ac‐ cess to their email addresses or phone numbers. A derived medical report could only display vitamin levels but leave out highly sensitive information such as HIV status, while leaving intact the prove‐ nance and trust of the original context.
In this section, we compare the impact of the document- and graph-centric pod interpretations in terms of storage, publication, and query processing. We highlight open research problems that need to be tackled for efficient graph-centric pod support.
In the document-centric interpretation, the underlying storage of a pod is typically managed as a document-based system, as evidenced by current Solid server implementations that leverage the file system or document-oriented databases. This preference is explained by the direct match of the in‐ terface to the pod; in some ways, the document-centric view on a pod can be seen as a permissioned file system for the Web. Of course, quadstore-based storage can also be applied, in which case the fourth element of each quad is usually necessary to indicate the document to which it belongs (and, hence, the associated metadata such as permissions). The benefit of the latter is that they might enable higher performance for derived APIs, although there is still the requirement of supporting non-RDF documents, such as images or movies.
The graph-centric interpretation imposes stronger requirements on the underlying storage. On the
one hand, different metadata might have different granularities, so there is no longer a natural docu‐
ment grouping. On the other hand, different selections need to be created from the raw data, so their
specific document organizations provide no universal benefit across APIs. Consequently,
documentbased storage systems are not a good technological fit. In the long term, native implementations of hy‐
brid, contextualized will be a necessity. In the medium term, they can be emulated on top of quadstores
and RDF-star stores [
The generation of API resources in the document-centric interpretation is relatively straightforward. Assuming the underlying storage system is indeed document-based, then each public-facing pod URL corresponds to an internal document identifier. Responding to an HTTP request involves looking up the internal document, verifying whether the document-based policies allow access, possibly performing a format translation, and sending it back to the client. Offering alternative APIs might involve more computations, depending on the underlying storage system.
The generation of API resources in the graph-centric interpretation involves a more complex process,
which harbors a significant part of future work in this area. First, we need the notion of a view defini‐
tion, which essentially specifies how public-facing pod URLs correspond to triples or documents from
the underlying hybrid knowledge graph. Next, a view application process is necessary for materializing
such view definitions to generate responses to concrete API requests. Furthermore, a policy definition is
required to express the allowed operations per triple, and a policy application process to apply this pol‐
icy to a specific request. To realize views, technologies such as RDF mappings [
In the document-centric interpretation, the complexity of the required query processing is mainly
impacted by whether or not the data resides in a single document, i.e., whether the concrete API of the
pod happens to coincide with the access patterns of a specific use case. Any mismatch requires
a multidocument selection, which might involve traversal-based query processing [
Since the graph-centric interpretation allows for multiple APIs, client can select those APIs that best
match the access patterns of their use case [
Different interpretations of the Solid vision come with different abilities to support that vision. The
dominant document-centric interpretation, specified by the Solid Protocol [
These issues have largely gone unnoticed so far, because singular apps only encounter smaller prob‐ lems, and different apps in a young ecosystem can still coordinate behind the scenes. However, an emergence of more Solid apps that need to interoperate has increased the frequency of such conflicts. Stopgaps that are being created to address them unfortunately only prolong unsustainable practices, as many issues are inherent to the implicit semantics within ad-hoc APIs. Proposals typically focus on making API semantics explicit [13, 28], yet they inherit the abstraction’s mismatches when it comes to aspects such as trust and provenance. This is why we instead suggest pushing the vision forward by separating the semantics from the API altogether.
We observe that the document-centric interpretation seems to act as a proxy for a more fundamental concept, namely a hybrid, contextualized knowledge graph that attaches metadata to data as well as documents. Our proposed graph-centric interpretation put this concept at the heart of each pod, and considers the Solid Protocol’s document interfaces to be specialized views of an underlying richer source of truth. This affords more flexibility—and hence independence—in how multiple apps can inter‐ act with the same data. Crucially, it also broadens the solution space for tackling interoperability chal‐ lenges. We are no longer confined to working around problems inherent to the single hierarchy, but can create solutions at the knowledge graph level and mint associated API views tailored to the needs and constraints of specific applications and use cases. To continue an earlier comparison: instead of being restricted to a two-dimensional environment, we have the full three-dimensional space at our disposi‐ tion for modeling solutions, which can then be projected onto as many two-dimensional surfaces as needed.
The graph-centric interpretation shifts the understanding from a data graph instantiated from a docu‐
ment organization, to a dynamically instantiated document interface over a data graph, paving the way
for fundamentally graph-centric data management within Solid. The separation of pod and APIs allows
apps to seamlessly interact via different interfaces to a pod, depending on what they are optimizing for.
It also opens the door for authorization with different granularities beyond one specific document
structure, and even for asymmetric read/write interfaces. They can eliminate the need for elaborate
mechanisms that explain where apps should write data [
The consequences of different interpretations of the Solid vision are not purely conceptual or theoret‐
ical: although implementers might have been unaware previously, even an implicit interpretation influ‐
ences how the storage, publication, and querying functionality of pods is realized into concrete prod‐
ucts. For instance, current implementations of alternative Web APIs to pods are affected by the doc‐
ument-centric interpretation, as a current Quad Pattern Fragments interface [
We stress that the current technical reports, notably the Solid Protocol [
Supported by SolidLab Vlaanderen (Flemish Government, EWI and RRF project V023/10).