Our goal should be to create a “world” in which machines speak machine languages over machine-friendly protocols. Where meaning is not as important as identity; Linking is not as important as data transfer; and human understanding is not as important as machine interpretation.
A machine-centered Web is possible today, the evidence is all around us. We only need to shift our gaze, alter our expectations, and change the way we communicate with the machines in our lives.
11. Maxwell’s Demon
• James Clerk Maxwell (1831 - 1879)
• “... if we conceive of a being whose faculties
are so sharpened that he can follow every
molecule in its course…”
• Second Law of
Thermodynamics
“has only a
statistical certainty”
12. Boltzmann
• Ludwig Boltzmann (1844 - 1906)
• “Boltzman entropy”
• Macro- & micro-states
• Each possibility is a microstate
• The probability of a
macrostate is the
function of all the
microstates.
13. Shannon & Information
• Claude Shannon (1916 – 2001)
• “The number of bits needed to represent the
result of an uncertain event is given by its
entropy.”
• Surprisal: the "surprise" of seeing the
outcome - a highly improbable
outcome is very surprising.
(Tribus, 1961)
14. Turing, Tapes, & Halting
• Alan Turing (1912 – 1954)
• A Turing machine is a hypothetical device
that manipulates symbols on a strip of tape
according to a table of rules.
• “Turing's paper ... contains, in essence, the
invention of the modern
computer.” (Minsky, 1967)
• “… decide whether the
program finishes running or
continues to run forever”
15. Gödel and Incompleteness
• Kurt Gödel (1906 – 1978)
• “This statement is unprovable.”
• Treats the string as both data and program
16. Von Neumann computing
• John von Neumann (1903 – 1957)
• Described a computer architecture in which
the data and the program are both stored in
the computer's memory in the same address
space.”
• Theory of Self
Reproducing
Automata (1966)
17. Genes
• DNA/RNA store both the data and program.
• mRNA uses “alternative splicing” where it
greatly increases biodiversity.
18. Fielding architecture
• Roy Fielding (1965 - )
• “Architectural Styles and the Design of
Network-based Software Architectures”
(2001)
• “each component cannot "see" beyond the
immediate layer with
which they are
interacting.”
• “…the information
becomes the
affordance…”
19. Complex Systems
• “Large networks of components with no
central control and simple rules of operation
give rise to collective behavior, sophisticated
information processing, and adaptation via
learning or evolution.” (Mitchell, 2001)
• “Exhibits non-trivial emergent and
self-organizing behavior.”
20. The Web
• “The Web … [has] many large scale
properties … which lead to “adaptive”
behavior for the system as a whole.”
(Mitchell 2001)
23. Media Types
• More registered hypermedia-style designs in
the last two years than in the last ten.
o Maze+XML (experimental)
o HAL (XML, JSON)
o Collection+JSON
o Siren (JSON)
o Hydra (JSON-LD)
o JSON-API (pending)
24. Media Types and entropy
• Designs vary in their level of “surprise”
• “surprisal” == “entropy”
• Lower the entropy, the less value the
information
• Higher the entropy, the more energy needed
to process the information.
25. Media Types and entropy
• text/uri-list
• Low entropy/surprisal
• Low energy needs
26. Media Types and entropy
• text/plain
• High entropy/surprisal
• High energy needs
27. Media Types and entropy
• text/html
• Moderate entropy/surprisal
• Moderate energy needs
28. Media Types and entropy
• From the “machine point of view”…
• What is the balance between entropy and
energy?
• Energy = computing power (coding time,
source code, memory, etc.)
29. Media Types and entropy
• Most applications on the Web are “one-off”
affairs - custom-coded for each solution.
• This is “high-energy computing!”
30. HTTP
• Hypertext Transfer Protocol
Ver 0.9 (1991) – Ver 1.1 (1999) <10 years
• HTTPbis (2013?) ~15 years since 1.1
• HTTP 2.0 (20??) >20 years since 1.1?
• No protocol-level
changes, but several
transport-level changes.
31. HTTP
• The Web is currently highly dependent on
a single protocol.
• Most new “protocols” build upon HTTP
o SPARQL 1.1 Graph Store HTTP Protocol.
• Most new media types assume HTTP
o JSON-LD
o HAL
32. The Irony of HTML and HTTP is…
It is difficult to imagine what it would be like without them.
33. Questions for you…
• How long will HTTP last?
• When will HTML no longer be dominant?
• How will this affect your own thinking?
• How will this affect the Web?
34. Kelvin-ism
• Lord Kelvin computed the age of the earth
based on “heat decay” and concluded:
“…it was more than 20 and less than 40
million year old, and probably much nearer
20 than 40”. (Kelvin, 1897)
• To his dying day, Kelvin refused to
accept the validity of other points
of view.
36. Near Term – Lowering entropy
• We need more media type designs
• We need to design for low-entropy and high
information
• We need to design for machines, not humans
37. Near Term – Lowering entropy
• Three semantic levels in network messages
o Structure (XML, JSON, YAML, etc.)
o Protocol (H-Factors)
o Semantics (Domain concepts)
• We commonly see:
o Structure = low surprise
o Protocol = high surprise
o Semantics = high surprise
38. The higher the surprise in the message, the
higher the dependence on custom code on the
client/server.
39. Near Term – Lowering entropy
• Hypermedia Factors can lower Protocol
Surprise
• Many designs are still unexplored.
40. Near Term – Lowering entropy
• Profiles can lower Semantic Surprise
• http://alps.io
41. Near Term – Lowering entropy
• We need more machine-oriented media
types.
• Text can add entropy for machines.
• rel=“users”
vs.
<a … >Users</a>
• Imagine a hypermedia type
that humans could not
understand, but machines could.
42. The higher the dependence on machine-
readable messages, the lower the entropy.
43. Near Term – Decoupling protocols
• Most media type designs today assume a
dependence on a single protocol – HTTP.
44. Near Term – Decoupling protocols
• Message designs should be protocol-
agnostic.
• Use “Protocol Mapping”
to associate media-type
keywords with a selected
protocol (HTTP, FTP,
WS, CoAP, etc.)
• http://g.mamund.com/class-sked
45. Near Term – Focusing on networks
• Most implementations are stand-alone, one-
off models.
• We treat the Web as a sea filled with islands,
each one only barely aware of the others.
46. “The WWW is fundamentally
a distributed hypermedia application.”
Richard Taylor (2010)
47. Near Term – Focusing on networks
• The Web, biology, & social communities
exhibit properties of a “scale-free” network
• Barabási-Albert model for “preferential
attachment” (1999)
48. Near Term
• Lower entropy in messages
• Reduce protocol dependence
• Treat the network as the application
51. Futures – No more central control
• If the WWW is the application, where is the
CPU? The storage? The program?
• Cellular Automata (Ulam & Von Neumann,
1940s)
• Conway’s Game of Life (1970s)
52. Futures – No more central control
• Cellular automata are discrete, abstract
computational systems
• In cellular automata information appears as
statistical probabilities.
• See Wolfram’s Atlas
http://atlas.wolfram.com/01/01/
53. Futures – No more central control
• Basic principles for automata
o Information takes the form of statistics and patterns
across the system
o Information is communicated via sampling
o There exists some level of random behavior
o Rely on fine-grained architecture, large numbers of
simple elements.
54. Futures – No more central control
• In “Future Web” we will create discrete,
abstract programs and they will interact
across the network.
• “What gets done on
the ‘net stays on
the ‘net.”
55. Futures – Adaptation via variation
• Machines will need to adapt to conditions,
learn and pass on traits.
• Learning happens via many passes and
survival of the ‘most fit’ for the task.
• “Robby” and the soda cans
o Start w/ 1xxx random attempts
o Score highest 2, splice
o Add random mutation
o Repeat
• http://g.mamund.com/robby
57. Futures – Competing for resources
• With Robby – there is a “score-keeper” for
the entire system.
• On the Web there is no score-keeper.
• In living systems, ‘scoring’ is done through
competing for limited resources.
58. Futures – Competing for resources
• In “Future Web” programs may compete for
scarce resources such as memory, storage,
cycles.
• RBNs (Random Boolean Networks) offer
a way to “keep score”
without central control.
(Kauffman, 1969).
• Uses attractors
o Fixed
o Oscillating
o Random
62. Summary
• However, our current efforts ignore these
features and contain a high degree of
entropy, coupling, and lack interdependence.
63. Summary
• We can start today by creating low-entropy
machine-oriented messages, decouple from
network protocols, and treat the network as a
single application space.
64. Summary
• In the future we’ll need to give up central
control, we’ll build discrete automata, and
we’ll create a network where variation and
competition are possible.