[Fiware-wpa] Approach regarding the whitepaper document about FI-WARE including description of common usage scenarios of FI-WARE GEs

[Juanjo Hierro]

Hi all,

  I'll try to describe the approach that we have agreed to follow, after some discussion during our regular confcall this morning, regarding development of the whitepaper document about FI-WARE including description of common usage scenarios of FI-WARE GEs.     Thanks to all those who contributed with rather good ideas that have helped to improve the approach proposed initially.

  In this description I will also give more details about the general approach that I had in mind.   I hope they will help to get a better clue of how the whitepaper / product-vision document may look like.

  The whitepaper would come as a result of reviewing the FI-WARE Product Vision, so that the following changes would be introduced:

  1.  Introduction would stay at it is now (see http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_Product_Vision).  Note that it would provide a link to the "Overall FI-WARE Vision" where the basic concepts of FI-WARE would get introduced.
  2.  Regarding each chapter, we will keep for sure the "Overview" and "Terms and Definitions" section.   We would essentially drop the contents linked to description of each individual GE that should go wherever it is appropriate in the Architecture Description of FI-WARE GEs (probably "Overview" and "Basic Concepts" sections) but we may also capture part of the description of each GE in the Overview section if suitable.
  3.  We will add per each of the chapters a number of sections each dealing with a description on how GEs in the chapter can be used or integrated, together or with other GEs from other chapters, in order to address a given common usage scenario.   This sections will become "recipes" that a given application developer can read to understand how to address/solve a given scenario.   Some of these scenarios will imply integration of GEs coming from several chapters, so we will have to make a choice regarding what is the chapter where description of the scenario will be more appropriate.   Some examples of sections dealing with description of usage scenarios are the following (the title may change):
     *   "Developing context-aware applications": here, we would elaborate on how several of the different GEs of the Data/Context Management chapter (particularly the Pub/Sub Broker GE, the CEP GE, the BigData GE, the Semantic Application Support GE and the Semantic Annotation Support GE) can be integrated together to support the notion of a "Context Managament Platform" that make it easier to develop context-aware applications.   We would explain how data gathered by the Pub/Sub Broker GE may feed the CEP GE so that this last one can trigger actions based on detected scenarios, for example.  We would also elaborate on how data generated by the CEP or the BigData GE may ultimately enrich context information, etc.   The natural place where this section could fit is would be the chapter on Data/Context Management.
     *   "Capturing data from the physical world and making it part of the context": here, we would elaborate on how data from sensors, captured through the IoT chapter GEs will feed the Context Broker, therefore the whole Context Management Platform we envision.   We may place this section in any of the two chapters, the IoT or the Data chapter, but we would go for a compromise so that, for example, this section would go into the IoT chapter and would be referred from somewhere in the Data Chapter (for example, the section on "Developing context-aware applications" where we can mention that "part of the contextual information may come from physical objects.  Check section on Capturing data from the physical world and making it part of the context" (text in blue would be link to the referred section)
     *   "Supporting an Open Data approach": here, we would elaborate on how the envisioned Context Management Platform could be used to support an Open Data approach.   We would elaborate on how organization willing to publish their data as open data would make that data available on a single Context Management platform linked to a FI-WARE Instance serving that purpose.   We would also elaborate on how such FI-WARE Instance may bring GEs for the Apps chapter enabling services from the Context Management Platform to be published so that it becomes available to third parties and even end users ...   Despite we would refer to GEs from the App Chapter, probably this section would fit more naturally as part of the Data/Context Management chapter, despite we may add a cross reference from the Apps Chapter
     *   "Authenticaded access to APIs exported by FI-WARE GEs": here, we would elaborate on what architecture is supported that will enable authenticaded access control to APIs provided by the GEs, relying on usage of the Identity Management GE.   The described architecture would be generic and should work for any GE, no matter what chapter it belongs to, but the description of the scenario would naturally fit as part of the Security chapter.
     *   etc.
  4.  Telefónica will come with a first draft of the FI-WARE Product Vision where we will drop out all those contents from the current FI-WARE Product Vision which will not longer be kept as part of the FI-WARE Product Vision.   We will try that this draft  be available by Wednesday EOB.   Together with this first draft, we will come with a list of "usage scenario" / "recipe" sections that we would like to propose for each chapter.    Once agreed with the corresponding chapter leader, it will be up to the chapter leader to organize the work as to deliver the final contents of each section.   Note that development of some of this "recipe" sections may require contribution by more than one chapter so they have to organize how contents will be developed (for example, section on "Supporting an Open Data approach").   Our suggestion is that the chapter leaders take the responsibility of providing a first draft of the section and then the other complementary chapters perform a peer review (following the same example, the Data/Context Management leader would provide a first draft of the section titled "Supporting an Open Data approach" and then the Apps Chapter Leader should review it).
  5.  We will share the table of contents derived from previous points with UC projects and will check whether they feel like there is some "usage scenario" / "recipe" section that is missing.   This would allow us to arrive at the review meeting with a document that has been validated by UC projects.


  Of course, we would work on a copy of the FI-WARE Product Vision we will setup on the FI-WARE Private Wiki.   We will replace the current FI-WARE Product Vision once a solid version is already available (may not contain all the final sections but at least consistent with the FI-WARE Architecture Description and Open Specifications)

  Let me repeat again the rationale behind this approach:  I may be wrong, but I believe that the reviewers look for something that is relatively stand-alone.  Something someone may read to get a clear vision about what we are envisioning in FI-WARE without too many references to other parts of the FI-WARE documentation.   In this respect, I believe it would be difficult to develop such a target whitepaper without repeating a lot of the good stuff that was already there in the FI-WARE Product Vision document (which, I remind you, got overall good acceptance by the reviewers).    On the other hand, introducing references to contents of the FI-WARE Product Vision doesn't solve the problem because we have found that peopled ends not reading the referred contents and, besides, even those sections on the current FI-WARE Product Vision that are in the best shape would still require some update.  Bottom line: it would be difficult to generate the target whitepaper without reviewing at least partially the FI-WARE Product Vision, at least to keep some consistency between the whitepaper and the FI-WARE Product Vision, so let's make it a single exercise.

  Your comments/feedback is welcome.  I will come with specific input regarding point 3 by Wednesday this week.

  Cheers,

-- Juanjo

-------------
Product Development and Innovation (PDI) - Telefonica Digital
website: www.tid.es<http://www.tid.es>
email: jhierro at tid.es<mailto:jhierro at tid.es>
twitter: twitter.com/JuanjoHierro

FI-WARE (European Future Internet Core Platform) Chief Architect

You can follow FI-WARE at:
  website:  http://www.fi-ware.eu
  facebook: http://www.facebook.com/pages/FI-WARE/251366491587242
  twitter:  http://twitter.com/FIware
  linkedIn: http://www.linkedin.com/groups/FIWARE-4239932





________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-wpa/attachments/20120924/08f35427/attachment.html>