A look at Solid and how it is likely to affect the evolution of the metaverse.

1. SOLID PODS
AND THE FUTURE OF
THE SPATIAL WEB
BY KURT CAGLE, KCAGLE@TECHTARGET.COM

2. THE PROBLEM WITH MODERN DATABASES
Primarily focused on
Enterprise, not Personal
Market
Frequently expensive to
license and/or operate.
Requires specialized
knowledge to populate
and query
Focused on large-scale
transactional data
Difficult to secure
information at granular
level
Interoperability Is not a
priority

3. YET THE LINKED DATA SEMANTIC WEB FAILED. WHY?
Early semantic web (2000-
2013) was clunky, verbose,
and byzantine.
Triple stores were a very
different paradigm than
what most were used to.
Predicate logic systems
(such as OWL) are suitable
for academics, not novices
Different systems evolved
different (often bespoke)
ontologies
Performance lagged
compared to SQL and
NoSQL systems
Utility of graph
programming was not
obvious.

4. REVISITING THE VISION OF THE
SEMANTIC WEB
In 2004, Tim Berners Lee outlined his vision of a semantic web in
Scientific American
 Individuals owned their own data, and others could only request
a snapshot with permission
 Data existed in graphs, but such graphs did not have to be
obvious
 Data can be aggregated through federation.
 Information should be secured by encryption.
 REST and Resource operations naturally lend themselves to a
folder/file structures and publishing paradigms
 Removing imperative structures (intent) to the extent possibility
is desirable

5. SOLID IS CONCEIVED
 In 2015, Tim Berners-Lee received initial
funding for a new project called Solid.
 Its goal was simple: figure out what it
would take to make data storage and
computing accessible to everyone.
 It would take advantage of advances in
computer speed, scalability, and the rise
of high-performance computing
platforms such as GPUs.
 Solid would also seek to resolve many of
the issues that had limited the adoption
of the Linked Data infrastructure.
 To do so, Solid would seek to redefine
people’s and organization’s relationship
to data.

6. PRINCIPLES OF SOLID
PODS
 A pod is a small deployable graph database offered by
multiple service providers.
 Pods can appear like file systems, although a given file
may be contained in more than one folder (container)
 Pods can also hold RDF content as native assertions.
 Multiple pods can be temporarily merged into virtual
pods or containers.
 Files, folders and assertions can have metadata that
affects access.
 Resources in pods are “secured” using encrypted
protocols
 Resources can be read or updated via CRUD
operations or via graph services

7. POD CONSTRAINTS
 Pods are best for storing contained, related data,
though it can be used as a web server or similar tool
 Pods use RDF to communicate with one another, but
the RDF can be Turtle, JSON-LD, XML or other
content
 Pods are graph databases, but do not have to be
triple stores, can be Turtle, JSON, XML, other.
 Pods are more akin to books than full libraries or
knowledge graphs
 Solid is a specification for Pods but is not a product.
 It’s useful to see a pod as a “domain” It has CORS
limits.
 Pods likely use SHACL or SPARQL on the back end,
but can use things like GraphQL in some cases.

8. SPATIAL WEB USES OF SOLID PODS
Pods provide separations
of concern
Pods can store scene
graphs
Pods can serve as data
catalogs for other pods
Pods can support or even
be distributed ledgers
(e.g., blockchain)
Pods can contain avatar
(user) information
Pods or pod containers
can server as pre-
calculated channels
Pods can hold knowledge
graphs, controlled
vocabularies, and
geospatial indices
Pods can be used as
intermediate calculating
nodes
Pod data can be reified
(rdf-star) to manage
versioning and
immutability.

9. PODS AS PLATFORMS
 Pods are ideally suited to run on GPUs
 This makes pods good environments for geo-spatial calculations
 Pods can be abstracted to train/deploy machine learning
classifiers
 Pods can segment Natural language processing, Lexicons, and
even NLG components
 Pods can serve gazeteer-specific data and act as index systems
for DSS-based Coordinates
 Pods can hold versioning data (temporally aware), point-in-time
graphs and archival data.
 Pods can also be run locally within clients to act as caching
systems

10. SPATIAL WEB STANDARDS AND SOLID
Please note that these are currently being studied, but nothing has been adopted yet.
 SW Specification adopts Solid as a Preferred Architecture
 SW makes no recommendations towards any given implementation of Solid
 SW provides extensions to Solid for Interprocess communication between SW Pods
 SW assumes no specific imperative language requirements, though assumes that Pods can be implemented or
extended via languages such as Javascript, Python, C#, C++, Java, Haskell, SPARQL and others.
 SW may define additional functional APIs that offer cross platform internal support
 Spatial Web standards efforts track and sync with the use of WebIDs/DiDs and Verifiable Credentials

11. QUESTIONS?