Download to read offline
Uploaded byPat Cappelaere
GEOSS Future Products & GeoSocial API
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 & GeoSocial API
- 1. GEOSS Future ProductsWorkshop 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 NeedYet 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 GapFor The International Disaster Community Big Data Big Data... Complex GeoSpatial API 3
- 4. Why: Conflicting APINeeds 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)
- 6. GeoSocial API isNot A Replacement API GeoSocial API Client Implementation SOA ROA REST RPC Service Implementation Workflows, Processes…
- 7. GEOSS Reality GEOSS UsersCannot 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 CareAbout 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: DesigningFor 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 ShouldPublish The Goals Goals Provide Activity Sequences (aka Behaviors) To Access Data 10
- 11. Users Need ToBe 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 OnlyState 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
- 14.
- 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
- #2 Due to time constraints, this presentation does not contain technical details. Please check out the various slide decks on slideshare.
- #3 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.
- #4 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.
- #5 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.
- #6 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.
- #7 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.
- #8 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.
- #9 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.
- #10 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.
- #11 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.
- #12 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.
- #13 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.
- #14 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
- #15 Activities get published in user timeline and news feed. They contain a picture of the generated product and links back to original product page.
- #16 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.
- #17 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.