1. A Open Geo-Social REST API For The Web
Lessons Learned From the EO-1 Spacecraft, 12 Years Later... Jan 1, 2013
Building the Next Generation Of Web Services Using Story-Telling.
The Way For Users To Get Information From The Programmable Web...
Or Could We Say?
Stories
1
2. Programmable Web Problem
# api’s
http://www.programmableweb.com/
This Is Becoming an Enormous Issue for Our Neo-Geographers
Too Complex... Too Much Coding...Too Little Time...
3. Our Geo-API Reality, Today!
Get Floodmap...
Disaster Floods - Port-Au-Prince, Haiti Get Flood Forecast...
60+ standards
at different version levels
3+ binding types
400+ Organizations
3
4. Before EO-1 EO-1 (Launched on Nov 21, 2000)
• Upload Individual Command • Upload A Goal
Sequences
• Execute the Goal
• Execute Command List
Manual, Complex, Time- • Satellite Generates Its Own
Consuming, Expensive Command Sequences Based on
Current Resource Availability
and Context
• Now We Can Say: Image Port-
Au-Prince, Haiti... and we get it.
Port-au-Prince, Haiti
4
5. EO-1 Wideband Advanced Recorder/Processor vs IPhone 5
Mongoose 5 Processor
32 bit, 12 MHz
6 GB Storage
3 GB Memory
23 kg
A6 Chip
32 bit, 1.3 GHz
64 GB Storage
1 GB Memory
112 g, $400
We Have Made Some Progress Since 2001... 5
6. Programming The [Geo-]Web Today...
• If You Want A FloodMap...
• Interface to EO-1 Sensor Planning Service... Get Feasibilities, Submit Task
• Interface to EO-1 Web Coverage Processing Service... Process FloodMap
Algorithm... Pan-sharpening Algorithm...
• Interface to EO-1 Sensor Alert Service... Get Notification
• Interface to EO-1 Sensor Observation Service... Get Data
• Repeat for Radarsat-2, MODIS (if you find them)... Use Catalog Service...
• And These Services May Have Different Bindings... REST/RPC, SOAP,
GeoServices or REST...
• Services May Have Particularities (To Task Radarsat-2, you may need to
specify beam mode, polarization... What is that?)
Manual, Complex, Time-Consuming, Expensive...
Does Not Scale Up For Our Disaster Community.
6
7. How Can We Reduce
Complexity And Improve
Access To Information?
Discovery, Harmonization & Interoperability Issues
[OGC REST Standard Working Group]
7
8. Standard User Media Types
Maps
and Stories
Recipes
144 ch.
Users Like Simple Directions and Stories.
8
9. Donald Norman: Designing For People
“Designers have to produce things that tame complexity.”
http://www.jnd.org
Stages of Execution:-
• Start at the top with the goal, the state that is to
be achieved.
• The goal is translated into an intention to do
some action.
• The intention must be translated into a set of
internal commands, an action sequence that can
be performed to satisfy the intention.
• The action sequence is still a mutual even:
nothing happens until it is executed, performed
upon the world.
The Design of Everyday Things. New York. 1986
9
10. Goal
What If...Like EO-1...
• User Would Only State the Goal
Get Floodmap...
Get Flood Forecast...
Floods - Port-Au-Prince, Haiti
• Services Would Figure Out What To Do and Return It To Client Some
Directions or Simple Maps (or Simple Model to Follow)
• Client Would Execute As Code-On-Demand (Simple Javascript Running In
Browser or Thin Client or SmartPhone App)
10
11. The Magick Sauce...
• We define user goals (in our case floodmap or flood_forecast...)
• To achieve those goals, we define [geo-]activities (see examples next slide)
• A behavior is defined as a set of [geo-]activities required to meet a goal.
• A behavior is encoded in Javascript as a behavior tree
• Servers publish behaviors/activities they can perform. They return possible
behaviors on query
• Simple Javascript library (or App) is provided to clients to execute returned
behavior trees
• Activities are triggered on the client but executed on the server
• Results are returned back to the user as atom feed or notification
User can execute the behaviors to meet a goal without having to read a spec,
implement an interfaces or workflow engine
11
13. Encoding Behavior...
Hierarchical Finite State Machines
Many Options... intuitive
reactive
HFSM
Existing
Game Technology
Behavior
Trees
Hierarchical Task Network Planners
Scripting
Workflows C++ Planners
LUA
autonomous
integrated purposefule
flexible Alex Champandard
http://aigamedev.com/open/articles/behavior-trees-part1/
http://aigamedev.com/open/articles/behavior-trees-part2/
13
http://aigamedev.com/open/articles/behavior-trees-part3/
14. A Simple Pattern
A Behavior Tree
To Model Behavior
Start From Goal At The Top
Goal G
do in parallel
Goal G:
Do Task1
Do All
1!
Only One if condition1 -> A1
1+ Then A2
Next Branch,
Do Task2
Task1 A2
✔ Task2
A4 if condition2 then A3
done!.
Cond1 A1 Cond2 A3
✔ ✔
Go Down The - Execution Strategy Options: Parallel, Sequential
or Select First Successful Branch Or Try Next Branch
Tree Until Action - Objects:
Goal
And Execute
Tasks,
Actions 14
Filters (conditions)
15. There Are Some Differences From Game AI!
Behaviors As Code-on-demand
• Behaviors Can Be Encoded in Javascript
• Behaviors Can Be Sent To Client on Request Based On User Goal
• Client Can Execute Behaviors in Browser (Javascript) and Execute Activities
On the Server Side By Following the Activity Links
• Smartphones... Tablets... and DeskTops...
• Activity Stories Propagate On Social Networks To Deliver Information and
Enable Discovery
• NO Need for Workflow Engine, Finite State Model Engine, Planner or
Compiler
15
21. Example
MODIS Behavior Tree for FloodMap
Goal
Floodmap
Activities
Tile
Avail?
Get
Product SOS
Only 1 Test, 1 Activity
1 OGC Service
Sensor Observation Service (SOS)
21
22. Example
RADARSAT-2 Behavior Tree for FloodMap
Floodmap
SPS Task
Asset Process
Data
GET
Product
SOS
WPS
GET
FEASIBILITIES
SUBMIT
TASK More Complex
Might Need To Task Satellite
3 OGC Services
Sensor Planning Service (SPS)
Web Processing Service (WPS)
Sensor Observation Service (SOS)
Optional Sensor Alert Service (SAS)... 22
23. Example
EO-1 Behavior Tree for FloodMap
Floodmap
SPS Task
Asset
PROCESS
FLOODMAP
Get
Product
SOS
ALGORITHM
WCPS
GET SUBMIT
FEASIBILITIES TASK
Then Need to Apply Special Algorithm...
3 OGC Services
Sensor Planning Service
Web Coverage Processing Service
23
Sensor Observation Service
24. Local User Tree For Floodmap (After Query)
Goal
Floodmap Three Behavior (sub)Trees To Execute in Parallel (or
Sequentially...)
Behavior Trees MODIS EO-1 RADARSAT2
Retrieved
Dynamically
.. .. .. ..
Client User Activities
Web Services
Server 24
25. Discovery Via Social Networks
Mimick
Share, Like,
Comment,
Collaborate...
Resources
Activity
Activity
Behavior Activity
Activity Activity
Stream
25
26. Discovery Via Distributed Query
Geo-Portals /
Federated Catalog Lookups /
Super Aggregators
Query
Client
Publish
Feed
Server
Behaviors
Behaviors
Behaviors
26
27. NEW
Agile Development Process + Implementation
• Focus On User Stories (Goals)
• Then Develop Scenarios (Behaviors)
• Then Implement Service The Same Way
Publish Goals/Activities/Behaviors
And Generate Activity Streams
27
Same inside as outside!
28. User Centric
Value Proposition
• Use Story Telling To Convey Information to Access/Share The Information
• Define User Activities To Interface To Actual Services
• Define Behaviors To Achieve User Goals By Sequencing Activities
• Web Services Publish Behaviors On Request Based On User Goals
• Users Execute Behaviors To Meet Goals and Retrieve Products
• Friends Discover Information/Capabilities On Social Networks Via Stories
(Activity Stream, Facebook, Twitter)
User Cares About Stories, Goals, Activities, Behaviors...
Not Services or Data 28
29. Floods - Port-Au-Prince, Haiti Get Floodmap
NextGEN GeoSocial API
User Goal Driven Behavior Tree
Realm
Activity Layer
Information/Goal G1 B2 G1 Independent of
Realm Service
Implementation
A1 A2 A3
Activity
Behaviors Orchestration
B1 B2 B3
Realm
S1 S2 S3
Activities A1 A2 A3 Service
Realm Implementation
Client Tomorrow's API GeoSocial API REST/RPC SOAP GeoServices
Today's API GeoSpatial API
Server Services S1 S2 S3
With Some Service OGC Service
Orchestration Standards
Realm
D1 D2 D3
Data
Realm
29