The document discusses the need for a new API for GEOSS users to discover and access future products. It notes that current OGC APIs are too low-level and difficult for typical GEOSS users, who are not professional software developers, to learn and use. It proposes a "GeoSocial API" that focuses on helping users meet specific goals, like generating a flood map, by providing activity sequences and behaviors driven by goals rather than exposing technical services and data models. The API would use techniques like hypermedia, action links, and code-on-demand to guide users step-by-step to access needed data and resources. Discovery would also be improved through active methods like story-telling in social networks and communities of interest.
GEOSS Future Products Workshop 2013: A GeoSocial API for GEOSS Users
1. GEOSS Future Products Workshop 2013
Mar 26-28 2013
A GeoSocial API for GEOSS Users Silver Spring MD
To Discover, Generate and Access Those Future Products
Pat Cappelaere
Email: pat@cappelaere.com
Twitter: @cappelaere
Slideshare: http://www.slideshare.net/cappelaere
LinkedIn: http://www.linkedin.com/pub/pat-
cappelaere/0/163/236
2. Do We Need Yet Another API?
• Current OGC API’s Too Hard for GEOSS
Users
• Too Low-Level, Too Hard to Learn,
Develop or Use
• What GEOSS User?
• Not a Professional Software Developer
• But Willing to Spend ~30mn to Learn An
API to Get Job Done
3. Big API Gap For The International
Disaster Community
Big
Data
Big Data... Complex GeoSpatial
API 3
4. Why: Conflicting API Needs
Engineers Big IT Investment
SOA
2000-2005
Better Move But
Still Too Low Level
REST RPC ROA (RESTful)
1995 2005-2012
GEOSS End Users (Mass
Market)
5.
6. GeoSocial API is Not A Replacement API
GeoSocial
API
Client
Implementation
SOA ROA REST
RPC
Service
Implementation
Workflows, Processes…
7. GEOSS Reality
GEOSS Users Cannot Care Less For:
• Your Services or Discovery of Those Services (ebRIM)
• Your Data Model or Your Resources
• Your Big Data or Even Linked Data
• Do Not Expose Any Of That to GEOSS Users! It does
not help.
8. GEOSS Users Care About
Products
So We Need To Help Them Meet Specific Goals Such As
Generating Specific Products (Ex: Flood Map)
This May Involve Satellite Tasking, Image Processing,
Notification, Distribution...
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. Your Services Should Publish The Goals
Goals
Provide
Activity
Sequences
(aka Behaviors)
To Access
Data 10
11. Users Need To Be Shown A Yellow Brick Road
To Follow
Hypermedia
Action Links
Code-on-demand
And Decision Gates On The Client Side!
Behaviors
12. Goal
Imagine…
• User Only State the Goal
Get Floodmap...
Get Flood Forecast...
Floods - Port-Au-Prince, Haiti
Others. Radarsat- EO-1 MODIS Landsa Models
. 2 t
• Web Services Figure Out What To Do and Return It To Client Some Simple
Steps to Follow)
• Client Executes Behaviors As Code-On-Demand (Simple Javascript Running
In Browser or Thin Client or SmartPhone App
12
13. GEOSS Discovery Recommendation
• Active Discovery via Story-Telling (Not ebRIM) through Social Networks and
Respective Communities of Interest (COI).
• You Tend To Do What Your Friends Do
• Use Activity Streams… and Pictures…
• Queries (OpenGraph)
• Supported by Products Light Semantics (RDFa)
African Drums
Telling Stories
in Jungle
16. Floods - Port-Au-Prince, Haiti
Get Flood Map
Client
Server
But Not A Replacement For Low Level API 16
17. An API for
People and
Machines
Viaduc de Millau, France
THANK YOU
Email: pat@cappelaere.com
Twitter:@cappelaere
Skype:patrice_cappelaere
17
http://www.slideshare.net/cappelaere
Editor's Notes
Due to time constraints, this presentation does not contain technical details. Please check out the various slide decks on slideshare.
For GEOSS users, the current OGC standards are to difficult to use, to learn and develop. GEOSS users are defined as non professional software developers that need access to imagery to respond to a disaster or use the data for GIS applications. They would be willing to spend 30mn to learn an API if needed but their software skills are limited.
This is unfortunate because we have the data (big data, open data) and we do have many APIs. But the gap is enormous. In most cases, the data is not readily accessible and used as needed by those neo-geographers.
OGC API’s originated in 1995 to respond to community needs. The second generation evolved based on serving the needs of the engineering community, DOD, NASA, ESA with very high skill levels and need for very strict interfaces. Although we are seeing a recent move towards a resource-oriented architecture (or RESTful services), it is becoming very obvious that even those services are too low level and still difficult to use. They are simply at the wrong level for the GEOSS community.
To generate a simple flood map, GEOSS users such as McCloud in Namibia need to master 60+ standards with API’s from 400+ organizations at different revision levels and binding types (RPC, SOA, ROA). Security is also another difficult hurdle that adds to the complexity of the system. Finding the right data, assets to task or imagery to process is simply too difficult.
We are not advocating yet another API to add to the mix but rather a client layer that could be used to help the user find a way to generate relevant products. This layer would be integrated as part of a user-agent on the local desktop, table or smart phone.
This new layer is required because the GEOSS users have different needs and concerns. They do not relate to our existing services or data models. They do not care about big data they do not understand or can relate to.
They care about relevant products for a particular situation in a specific area of the world. They want to generate products that may involve satellite tasking, image processing and data distribution without having to master the specifics of the various interfaces.
We need API designed for people to tame the inherent complexity of the various operations. It starts with a goal that can be translated into a set of activities to be performed upon the world.
As services, we need to publish the goals that are possible and the activity sequences provided as behaviors to follow to access the “big” data and transform it into relevant products to can be turned into actionable information.
We are talking about generation an action map or behavior. This can be encapsulated as code-on-demand downloaded from the servers. That code would contain various links to follow based on some decision gates that may require user input. This runs on the client side on behalf of the user.
In our case, it becomes easy to imagine our user requesting a flood map for Haiti or Rundu, Namibia. Behaviors may come back from various services handling radarsat-2, EO-1, MODIS, Landsat-8, models and many others. These behaviors would run on the client side and eventually generate the desired products.
Discovering potential products can be done within the existing social environment of the users. In that case, discovery is simply done via story-telling: the most natural way for humans to convey information. African drums used to tell stories in the jungle, alerting of arriving foreigners at more than 100 miles per hour. Leveraging the social networks, stories can become viral quickly. Within an existing community of interest, users will tend to do what others did successfully. Activity streams and active links can help point users to the original activity sequence and generate a similar product
Activities get published in user timeline and news feed. They contain a picture of the generated product and links back to original product page.
Various activities can be published. Feasibilities, tasking and image processing. This increases the chance of discovery from friends. OpenGraph queries are of course possible at any time.
This describes the various layers of the next generation GeoSocial API. Bottom layer has the traditional data and service APIs. We are adding an activity layer and a behavior layer to enable users to generate published products or goals.