GeoBliki's Blog :

Should Sept 1 be API Day?

Mon, 21 Jan 2013 01:36:00 +0000

API Days Are Over!

Sun, 13 Jan 2013 21:47:00 +0000

New Year Resolution: An Open GeoSocial REST API

Wed, 02 Jan 2013 00:33:00 +0000

Happy New Year to the GIS and Disaster Communities.

My New Year Resolution is to get this done:

Open GeoSocial API from cappelaere

APIDays Rocked!

Mon, 17 Dec 2012 15:03:00 +0000

Finally got back and recovered from this great conference in Paris. There is definetely something happening in Europe. Keep it going! I might even go back more often.

Here are my slides if you are interested in the next generation APIs for the web:

REST Level 5 - A Trek To The Summit from cappelaere

AIP-5 Disaster Management

Wed, 21 Nov 2012 15:30:00 +0000

Here is a great video to illustrate some of the work NASA and many other organizations are doing to support Disaster Management. Standards come in play during those difficult times. There is still a considerable amount of effort to be done to help end-users navigate through this maze. This will give you an idea of what the process entails. Moving the API’s to a level 5 is essential to the CEOS/GEOSS Community. Enjoy!

AIP-5 Disasters Management from Hervé Caumont on Vimeo.

How to Reach [EV] REST Level 5: the Summit

Wed, 07 Nov 2012 16:18:00 +0000

At RESTFest 2012, Stu Charlton’s keynote described user agents acting on behalf of users, crawling the web for activities they could perform to meet user goals. He presented the idea of using linked behavior trees. Hummm… seemed easier said than done… but what an incredible vision! How can we get there?

The journey starts at Richardson’s REST level 3. You need to have hypermedia controls, action links and code on demand… In our case, javascript is a necessity as it can be requested on-demand and executed on the client side as well as on the server side. You can find more background info in my previous slides.

The next step is to think in terms of user activities (or GeoActivities for the OGC community interested in location and spatial objects). Activities are made of {verb} {object} [{target} {context}]. When performed, they can be output as activity streams. They can be published and queried at will. To perform a goal, many activities may be performed remotely by one or more web applications. For every web application, a local behavior tree needs to be assembled to cobble up specific activities to be performed to meet a specific goal. From a user standpoint, a goal is an "prized" object of interest.

For example, In our case, a user may be interested in a "floodmap" for a specific area of the world at a specific lat/long in some format (GeoTiff or KMZ). A distributed query can fetch (as links returned from the query) local behavior trees from existing services (MODIS, RADARSAT-2 and EO-1). Some of those services may even task a satellite and process the data to meet the user request while another may retireve the daily MODIS floodmap product. Local trees are asembled on the client side in a bigger tree to be executed in parallel to completion. One or more products are acquired and made available through links to our user. A piece of cake :)

Behavior trees can be expressed in JSON. Each node is an activity expressed by a verb that enacts the behavior for that state. That activity may or may not be executed depending on context. You have to define a guard to allow or reject the state transition and move to another state as required or continue on.

The basic code can be found there. You may need to tweek it slightly to run under node.js. Thank you Marie Rose Cook for sharing it. A user-agent can now request the local behavior trees and execute them on the client side. Pretty cool!

To describe activities and objects a little better, you may want to check out the Facebook OpenGraph approach. They have an interesting lightweight RDFa approach to link "big" data within social networks. Querying for local tree may entail a little SPARQL or FQL.

So here it is: REST Summit at level 5.

Enjoy the view.

What Makes a Great API (or What Makes It Stick?)

Thu, 11 Oct 2012 12:49:00 +0000

This is the year of the API. The numbers are staggering. If you are successful, it could be in billions of API calls PER DAY!

With the money at stake, it becomes crucial to get it right.

If you have a few minutes, check this presentation from John Musser (ProgrammingWeb) or even this one.

If you can spend a few days in NYC Nov 1-2, you must go to the API Strategy and Practice Conference, Westin Grand Central. Aiming for a REST API is not the end of the journey. Your users might not care about your data model and internal plumbing. They do care about stories they can relate to, read about. They care about stories from trusted friends that can lead them to activities they can perform. This is what makes an API stick and get adopted. This is my story and I am sticking to it. Hope to see you at the conference.

What are Resources in an Architecture at Maturity Level 4?

Thu, 20 Sep 2012 12:46:00 +0000

RESTFul services can be implemented at increasing levels of maturity. The next level is not defined yet but if there were a level 4, resources will likely be objects in an Open Graph. An Open Graph is a way to visualize Linked Objects on the Web. Linked Objects or Linked Data is now emerging from the Semantic Web world to the consumer world. This has been driven by Facebook recent (2010) offering with the Open Graph Protocol. This protocol is now open source and supported by many big corporations. A light version of RDFa is used to describe the various node types on the network.

Interestingly enough, objects can also be connected by Action Links (or verbs). Verbs can be customized by the web applications to allow for a user centric API. Everything becomes an activity involving a user, object and a target. When performed, the resulting activity can be added to the user activity stream and added to his timeline. Friends see those activities, may comment on them and… it could go viral from there. The Activity Stream protocol has been defined for Atom and JSON and is now widely adopted. So rather than simple hypermedia links between resources, we need to think in terms of Activity Links between a user and objects of interest.

The current problem is that Facebook is a closed proprietary system. Not all web services may want to be in the Facebook realm. We need to think of a true open way of building services at a similar level but in a distributed fashion.

Still missing to the level 4 architecture is discovery. This would be the capability to search for Linked Objects and get back the activity handles that would allow a user (or rather a user-agent like SIRI for example) to perform such activities using that web app. A smart agent could crawl the web, find the options to match the user goals, select the best alternative based on user criteria and return the desired "product" to the original user. More on this later…

Building Tomorrow's Web Services

Mon, 17 Sep 2012 13:06:00 +0000

After three days in Greenville, SC, at the REST FEST 2012, it finally dawned on me that the web services we are building today will not meet the needs of tomorrow’s users.
Actually, the primary users of your web site will not even be human. They are more likely to be user-agents that will interact with many services on your behalf. Those user agents may be embedded in your iPhone or IPAD. They already are to some extent (Think SIRI).

Web interactions are changing. You will not browse a web site directly and download content anymore. An agent will do that on your behalf but only under some very specific conditions. It will have to find that site or rather its offerings and but only if they match your needs.

How will that work?

At the highest level, you may have a need that you want to fulfill. This need or goal might breakdown in many activity sequences depending on the choices you may be able to make (based on availability and constraints). Your agent needs to crawl the web and find what’s avtoailable. Choices can then be made (by the agent or yourself), activities executed and goal be met.

From an API standpoint, enterprise services need to evolve to that model. We simply cannot resort to publishing resources and use hypermedia (Resource Oriented architecture using REST) as conceived more than 12 years ago by Roy Fielding. This is unlikely to work unless it matches what the agent is looking for.

As an example, this is a salient problem for NASA. How to match NASA resources and assets to user needs?

NASA may make MODIS/RADARSAT data available on a web site but how does this match a user need?
User does not know MODIS or RADARSAT.
User wants to perform an activity: {verb} {object} {target}
> get floodmap of Haiti

More advanced science users may something more specific:
> get "radarsat-2 ortho-rectified raw data" of Haiti

User-agents of all kinds will need to be able to find and retrieve activities that the site can perform.

This is basically what I am trying to describe here:

Building Tomorrow’s Web Services from cappelaere

Let’s work towards an Activity-Oriented Architecture rather than publish resources and links.

RIP is out!

Mon, 10 Sep 2012 14:43:00 +0000

Here is a 5mn slideshare on RIP: A framework to analyse and evaluate RESTful services. This will be the basis for a 5mn presentation at REST Fest 2012 at the end of this week in Greenville, SC.

RESTful Patterns for [OGC] Enterprise Services

Sun, 19 Aug 2012 12:13:00 +0000

This is the title of the presentation I will be giving at RESTFest 2012, Sept 13-15th in Greenville, SC.

"Let’s imagine a SensorWeb with millions of services of various types that could be accessed by humans or automatically by machines over the web. Let’s imagine sensor gauges in Namibia connected to forecasting models in the US and earth-orbiting satellites ready to image the upcoming flood on-demand. What architectural patterns may be required of these services to meet the challenge? Based on many observed best practices, which ones may need to be instituted for seamless interoperability over time? The Open Geospatial Consortium has defined a multitude of standardized services. Over the last 25 years, those standards have evolved from a REST/RPC style to SOAP and a newer binding style is now being considered. This presentation will focus on some of the contemplated best practices that could be used to define a policy for a REST/Hypermedia API to be used at this enterprise level"

Intelligent Payload Processing for New Decadal Missions

Fri, 18 May 2012 22:04:00 +0000

The time has come for intelligent image processing onboard the spacecraft to provide real-time ad-hoc products to our end-users. This presentation was given at the HyspIRI workshop at the NASA Greenbelt Technology Center. Scan the tag to access the screencast… if you know about Microsoft Tags!

Intelligent Payload Processing

View more PowerPoint from cappelaere

Wounded Warriors On the Bay #2

Sun, 15 Apr 2012 13:21:00 +0000

May 25th is approaching very quickly. This will be our second annual event for wounded warriors and sailors. If you are interest in participating or sponsoring the event, please contact Bill Dietrich bill@twotopadaptive.org.

The TwoTop Adaptive Sports Foundation is doing some remarkable work at Whitetail during the winter and is currently looking into expanding its program during the summer.

Please visit TwoTop www.twotopadaptive.org and leave a message of support on Facebook www.facebook.com/pages/Two-Top-Adaptive/188111477876772

Thanks.

Geobliki comes back from the Eastport-Solomons

Mon, 19 Jul 2010 14:31:00 +0000

Picture taken by John & Toni Knisley passing us by on our way back from the Eastport-Solomons night race before a 20knot squall hit us. This was a blast.

Geospatial Apps Help Temper Mother Nature's Fury

Tue, 06 Apr 2010 23:21:00 +0000

Here is a very good write up in Federal Computer Week regarding our current work with the Namibia Flood Pilot. The prototype can be openly access on our Campaign Manager website (which is unfortunately restricted to most users).

Sensor Web Project Generating Buzz and Benefiting Society

Thu, 25 Feb 2010 13:21:00 +0000

FYI: A "Did You Know" on your Sensor 3G work (attached) was presented and distributed on Feb 23rd at the Headquarters Earth Science Directorate Staff
meeting by the Earth Science and Technology Office management.

2-Factor Authentication for SensorWeb

Tue, 29 Dec 2009 03:48:00 +0000

Securing transactional RESTFul OGC Web Services is a challenge but can be done using a hybrid OpenID/OAuth protocol (see OGC OWS-6 interoperability demonstration).

To increase the security assurance level beyond level-1, you need to use more than one authentication factor such as: something you know (password) and something you have (keyfob). Our openid server is currently being upgraded to support Verisign Identity Protection (VIP) and VIP Access using Mobile Credentials (free for end-users).

If you register a credential in your profile, a security code can now be used in addition to a password to gain access to the SensorWeb services. A security code can also be used to delegate user authority to consumer applications such as workflows to access services on your behalf. Credentials will become mandatory to gain access to satellites and UAV tasking request over the web. There will still be an air gap between users and assets but, at least, user identity will be known with very high confidence.

Our goal is to demonstrate that it can be done simply, cheaply and RESTfully.

Proposal For A NASA Virtual Currency to Demonstrate Value

Thu, 17 Sep 2009 20:50:00 +0000

September 17, 2009, in the Wall Street Journal, Andy Pasztor writes:

"PASADENA, Calif. – NASA’s No. 2 official on Wednesday vowed to provide taxpayers "better value" by focusing on environmental goals and promoting science education"

Problem is: How do we demonstrate value for "free" data? For a particular program, one could build a model to demonstrate that value could be generated (see NOAA Portfolio Analysis). This could end up being very costly. The other issue is: how accurate or realistic would those models be?

A better way is to provide an environment that can enable the emergence of sustainable ecosystems powered by an american concept: A "Free" Market approach to value. Let the user communities place value on the NASA data they want to aquire or assets they want to task, and even compete for that data or assets if necessary.

What better demonstration of "Value"? What a better way to get communities involved and point to us what they "value"?

The idea is to create a NASA virtual currency or NASA dollars that could be used to access data or task NASA assets when needed. Users would need to demonstrate value creation and would receive equivalent NASA purchasing power as they see fit at no "real" cost to the users. The useage of this virtual currency would be a great indicator of value as perceived by the user community. When some users or some community can justify increased creation value, they would receive more NASA dollars. If you cannot justify value creation, you would simply become second class citizen. No need for an enforcer. Let the Free market decide.

This could also help with Basic Science Research. Let’s have scientists justify value for their research too. They would be getting hints on user needs after all. This could be done various ways: from measuring their scientific paper publications and counting the references to those papers to measuring a "Return On Investment" based on science applications and direct technology infusion that eventually will lead to market growth.

This would be a major technology break-through driven by pure economics. Isn’t this the American Way after all :). Not that easy but not rocket science either. I am sure that several universities would love to provide guidance to this new frontier for NASA.

Here is an idea for a name for the new currency (since it does not cost anything):

PubSubHubBub: Real-time Event Notifications For Our OGC Services

Sat, 12 Sep 2009 16:35:00 +0000

Leveraging another Google feat with the newly minted PubSubHubBub protocol or PSHB, interested users can now get real-time notifications when new products from EO-1 are available. Rather than polling our server at: http://geobpms.geobliki.com/products.atom, consumers can subscribe for that feed at: http://pubsubhubbub.appspot.com/subscribe.

They can enter their own callback to receive changes as it happens.

This capability is also now built-in Feedburner, Google Alerts and Google Reader. More on TechCrunch

The same feed is available on FeedBurner: http://feeds.feedburner.com/Eo-1Level2ProductFeed

But why would you subscribe to it there? unless you are a human!

Feel free to use Google Reader and add that feed to your favorites.

Pat.

Geobliki on The Chesapeake Bay

Mon, 31 Aug 2009 12:53:00 +0000

Geobliki is getting ready to take on the Chesapeake bay!

Looking forward to seeing you there :)