New Year Resolution: An Open GeoSocial REST API

Posted by Patrice Cappelaere Wed, 02 Jan 2013 00:33:00 GMT

Happy New Year to the GIS and Disaster Communities. 

My New Year Resolution is to get this done:

 

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

Posted by Patrice Cappelaere Wed, 07 Nov 2012 16:18:00 GMT

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?)

Posted by Patrice Cappelaere Thu, 11 Oct 2012 12:49:00 GMT

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?

Posted by Patrice Cappelaere Thu, 20 Sep 2012 12:46:00 GMT

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

Posted by Patrice Cappelaere Mon, 17 Sep 2012 13:06:00 GMT

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:

 

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

Older posts: 1 2 3