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.
1. GEOSS Future Products Workshop 2013 Mar 26-28 2013A GeoSocial API for GEOSS Users Silver Spring MDTo Discover, Generate and Access Those Future ProductsPat CappelaereEmail: email@example.comTwitter: @cappelaereSlideshare: http://www.slideshare.net/cappelaereLinkedIn: 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 NeedsEngineers 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. GeoSocial API is Not A Replacement API GeoSocial APIClientImplementation SOA ROA REST RPCServiceImplementation Workflows, Processes…
6. GEOSS RealityGEOSS 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.
7. GEOSS Users Care AboutProductsSo We Need To Help Them Meet Specific Goals Such AsGenerating Specific Products (Ex: Flood Map)This May Involve Satellite Tasking, Image Processing,Notification, Distribution...
8. Donald Norman: Designing For People “Designers have to produce things that tame complexity.” http://www.jnd.orgStages of Execution:-•Start at the top with the goal, the state that is tobe achieved.•The goal is translated into an intention to do someaction.•The intention must be translated into a set of internalcommands, an action sequence that can be performedto satisfy the intention.•The action sequence is still a mutual even: nothinghappens until it is executed, performed upon theworld. The Design of Everyday Things. New York. 1986 9
9. Your Services Should Publish The Goals Goals Provide ActivitySequences (aka Behaviors)To Access Data 10
10. Users Need To Be Shown A Yellow Brick RoadTo FollowHypermediaAction LinksCode-on-demandAnd Decision Gates On The Client Side! Behaviors
12. 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
13. Facebook Story-Telling
14. Floods - Port-Au-Prince, Haiti Get Flood MapClientServerBut Not A Replacement For Low Level API 16
15. An API for People and MachinesViaduc de Millau, France THANK YOU Email: firstname.lastname@example.org Twitter:@cappelaere Skype:patrice_cappelaere 17 http://www.slideshare.net/cappelaere