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