QuWeDa 2022
What's In A Pod?

What is a Pod?

• Personal Online Datastore
  • Keeping people in control of their data
• Separation of Application and Data
  • By separating applications and the data they use, we create independent choices.

From a Web of tight coupling

Towards personal data management

A document-centric Pod

• • 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.

A document-centric Pod

• Solid stores data as a hierarchy of RDF documents
  • Applications write data to the Pod modeled
    to their real-world knowledge of the data.

• 

A document-centric Pod

• Solid stores data as a hierarchy of RDF documents
  • There are many ways to model real-world data
    where the Solid document hierarchy allows only one

• 

  

The document hierarchy leaves degrees of freedom

• The Solid protocol enables client apps to define their own APIs within the Pod's URL space.
  • Even for a limited ecosystem, we need agreements on data storage to enable application interoperability.

The Solid document hierarchy
carries document-based semantics

The Solid document organization is coupled
to other aspects of the data, that are
limited to (one) document granularity

Data modeling mismatches

• The single document hierarchy
  coupled with document-based semantics
  leads to mismatches in the modeling of data

Even simple examples are limited
by the single document hierarchy

Even simple examples are limited
by the single document hierarchy

Even simple examples are limited
by the single document hierarchy

Alternative APIs

• Any API derived from the document hierarchy of the data Pod is limited by its granularity and its explicit and implicit modeling aspects.

To query a resource, you need read access!
If the birthday application does a query for a contact, you have to give it access and trust it with the full set of contact data!

A graph-centric Pod

A multi-dimensional data space

• The Solid document hierarchy
  is but one 2D view of a
  higher-dimensional data space

A graph-centric Pod

• We present the following definition:
  
  
  • 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 “contextualized” the ability to associate each of its individual documents and statements with metadata such as policies, provenance, and trust

Aspects of the RDF data graph

• A graph-centric interpretation of the Solid Pod
  enables us to encode the aspects of its data
  directly in the Pod knowledge graph.
  • Hence, we define it as a contextualized knowledge graph.
• These aspects can be assigned in different granularities over the data graph.
  • Triples can share the same provenance, but have different policies applied.
• These can be reflected in the APIs that are built on top of the Pod knowledge graph.

We can derive any document hierarchy
as a projection of our Pod KG

New storage requirements

• A single document hierarchy only requires
  a direct file system mapping
• A multi-dimensional data graph requires
  more specific storage solutions
  • Different grantularities of aspects lead to
    dynamic groupings of data.
  • In the medium term, we can emulate these
    on RDF-star stores.

API-dependent publication

• In the current document hierarchy
  published documents correspond to a URI.
• In a graph-centric Pod, the generation
  of resources is dependent on the API
  • Dereferencability depends on the interfaces

Querying

• In a document hierarchy, querying consists of
  discovering and retrieving
  all documents relevant to the query.
• In a graph-centric Pod, clients can select the APIs that are the best match for their query.
  • The increased expressiveness that these APIs allow
    invite clients to build their own abstractions on top.

To enable the Pod-as-KG model,
we ask to abandon:

• The notion that one view would be more special than all others
  • Where a single document hierarchy is more simple and developer friendly, it limits the ecosystem in ways we can already see today.

We cannot model reality in a single document hierarchy

• We cannot possibly standardize document structures for all domains.
• To manage such a single document hierarchy
  we require complex solutions.
• The Pod-as-KG interpretation allows us to design
  more efficient solutions for the ecosystem!